Daily updates from Odoo
Wednesday, January 21, 2026
191 changes
24 changes
Resolved issues and error corrections
This update removes a redundant 'OK' button from form dialogs within the Point of Sale system. Previously, this change only applied when the 'pos_appointment' module was active. Now, the change is consistent across all POS form dialogs, providing a cleaner and more streamlined user experience.
Original PR description
Before this commit: =================== - The extra `OK` button in form view dialogs was removed only when the `pos_appointment` module was installed. After this commit: ================== - The CSS to remove the extra `OK` button has been moved from `pos_appointment` to the base `point_of_sale` module, ensuring consistent behavior across POS form dialogs. Task:5406858 Related Enterprise PR: https://github.com/odoo/enterprise/pull/102197 Forward-Port-Of: odoo/odoo#240165
This update removes a redundant 'OK' button from POS form dialogs, ensuring a cleaner and more consistent user experience across all Point of Sale operations. The change was made to standardize the styling across the entire POS module, previously the removal was only applied when the `pos_appointment` module was installed.
Original PR description
Before this commit: =================== - The extra `OK` button in form view dialogs was removed only when the `pos_appointment` module was installed. After this commit: ================== - The CSS to remove the extra `OK` button has been moved from `pos_appointment` to the base `point_of_sale` module, ensuring consistent behavior across POS form dialogs. Task: 5406858 Related Community PR: https://github.com/odoo/odoo/pull/240165 Forward-Port-Of: odoo/enterprise#102197
This update resolves a potential issue where the website editor could fail due to timing problems when opening. By ensuring the editor waits for the iframe to fully load, the editor now works consistently and reliably, especially on slower network connections. This improves the user experience for creating and editing website content.
Original PR description
Steps to reproduce: 1. Set network speed to 3G 2. Create website Page from the systry new menu 3. click on edit button You'll face the traceback. The website editor could try to open before the iframe finished loading, leading to non-deterministic behavior. This commit ensures the editor initializes only after the iframe load event, making the edit action consistent and reliable. Erlier fixed was not covering the all the cases. PR: https://github.com/odoo/odoo/pull/238054 runbot-233039 Forward-Port-Of: odoo/odoo#243256
This update simplifies the process of managing product pricing tags. The 'update all' button has been removed, and now only the buttons for products that have been edited will function. This change streamlines the workflow for pricing adjustments.
Original PR description
To ease update of pricer tags, we removed the "update all" button to only have the one that update edited products. Task: 5380332 Forward-Port-Of: odoo/enterprise#103114
This update fixes a technical issue that could cause list views to crash when aggregating data from certain financial fields. The change ensures that the system gracefully handles situations where currency information isn't automatically provided, preventing errors and improving data reliability in reports and dashboards.
Original PR description
This commit resolves a traceback during list view aggregation when the view is grouped. The crash occurred specifically when aggregating a `float` field that uses the `monetary` widget. Unlike true `monetary` fields, the server does not automatically send a `currency_id` aggregate for `float` fields. The aggregation logic previously failed when this data was missing; it now handles the case by ignoring it since it's not supported. opw-5725692 Forward-Port-Of: odoo/odoo#244548
This update resolves a test failure related to marking inbox messages as read when opening a channel in Odoo. Previously, the test was unreliable due to messages being fetched before the expected RPC call. This change ensures the initial fetch occurs first, guaranteeing the test's consistent results.
Original PR description
The `Opening thread with needaction messages should mark all messages of thread as read` ensures that opening a channel marks the related inbox messages as read. However, this test can fail in a non-deterministic fashion. There are two flows that can mark inbox messages as read: fetching the messages or a manual request after opening the channel. The test expects the rpc to be issued, but if the messages are fetched before, it won't happen thus making the test fail. This commit awaits the initial fetch to prevent this issue. As a bonus, the second flow is also tested. runbot-237970 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#244693
This update fixes a visual issue where the 'Invite a User' dialog in the discuss app didn't fully utilize the available screen space. The fix ensures the dialog expands to the full width of the modal window, regardless of screen size. This improves the user experience and ensures consistent appearance.
Original PR description
Before this commit, the channel invitation dialog had its content not taking the whole width of modal. Steps to reproduce: - Have window take about half size of a 1080p monitor - Open "General" in…
Before this commit, the channel invitation dialog had its content not taking the whole width of modal. Steps to reproduce: - Have window take about half size of a 1080p monitor - Open "General" in discuss app - Open the Member list - Click on "Invite a User" => Invitation dialog takes about half of the width of modal. This happens because the channel invitation was wrongly assumed to be inside a resizable panel, and thus the size was limited by the max width when in resizable panel. The rule to determine whether the action is in a resizable panel was poor: any action panel in discuss app was considered as resizable. This commit fixes the issue by limiting the responsive sizing, intended only for resizable panel, only when the action panel has the `.o_resizable_panel`, which is specific to when action panel is being used inside resizable panel. Task-5804100 Before / After <img width="625" height="231" alt="Screenshot 2026-01-20 at 16 12 31" src="https://github.com/user-attachments/assets/10c02939-c4c1-47fa-82f8-4d8d037d3f0c" /> <img width="621" height="231" alt="Screenshot 2026-01-20 at 16 12 18" src="https://github.com/user-attachments/assets/eec1447c-cb42-4751-b17a-ff7b2e70b8e9" />
This update resolves an issue where the employee presence status widget incorrectly displayed for archived employees. The code has been updated to hide this widget when an employee record is marked as inactive, improving the user experience and ensuring consistent data presentation.
Original PR description
**Steps to reproduce:** Navigate to Employees -> Open an archived employee -> the presence status appears below the Archived banner **Solution:** Hide the presense status widget when the employee is inactive Task: 5350479 Forward-Port-Of: odoo/odoo#236947
This update corrects a visual bug where an 'Add Item' button incorrectly remained visible when no topics were present in a web page snippet. The fix ensures the button disappears when there are no topics, preventing a technical error. This improves the user experience by removing unnecessary elements.
Original PR description
Steps to reproduce: - Drag and drop a "Topics List" snippet onto a web page. - Remove all "Topic" items from the snippet so that none remain. - Click the "Add New" button. - A traceback occurs. This bug is caused by the fact that the "Add item" option is defined in the "Options" section of the parent element of the topics. As a result, the option button remains visible even when no topics exist anymore. Clicking it then triggers a traceback because the option attempts to duplicate an element that does not exist. In this commit, we fix the issue by adding an "applyTo" on the option, targeting the topics, so that the "Add New" button no longer appears when no topic is present. Note that the same bug exists for other snippets, and this commit fixes them as well. task-5462596 Forward-Port-Of: odoo/odoo#244126 Forward-Port-Of: odoo/odoo#244034
This update resolves an issue preventing users with the Romanian language pack installed for the l10n_ro_edi_stock module from accessing the settings app. The fix corrects a mismatch in the system's search for translated text, ensuring proper functionality in Romanian.
Original PR description
**Issue**: When the module `l10n_ro_edi_stock` is installed and Romanian is the selected language, accessing the settings app causes a traceback. **Steps to reproduce**: - Install the module…
**Issue**: When the module `l10n_ro_edi_stock` is installed and Romanian is the selected language, accessing the settings app causes a traceback. **Steps to reproduce**: - Install the module `l10n_ro_edi_stock` - Select a Romanian company - In Profile > My Preferences > select Romanian language - Try to access the settings -> A traceback occurs **Cause**: The error is caused by this XPath: https://github.com/odoo/odoo/blob/2309fb56553e6ae9f89b6dd0947aba2f54408960/addons/l10n_ro_edi_stock/views/res_config_settings_views.xml#L9C13-L11C21 Specifically, the `'select the option'` part. The XPath tries to replace this line in the parent view: https://github.com/odoo/odoo/blob/2309fb56553e6ae9f89b6dd0947aba2f54408960/addons/l10n_ro_edi/views/res_config_settings_views.xml#L39 but fails to find it because the source text has already been translated at that point, so `'select the option'` no longer matches: https://github.com/odoo/odoo/blob/2309fb56553e6ae9f89b6dd0947aba2f54408960/odoo/tools/template_inheritance.py#L154 **Solution** Only rely on strings that are translation-invariant. opw-5490346 Forward-Port-Of: odoo/odoo#244313
This update corrects a calculation error in the fleet module related to the initial date of vehicle acquisition. By setting a default acquisition date, the system now accurately calculates baseline ATN (Activity Tracking Network) metrics, leading to more reliable fleet performance reporting. This ensures better insights into vehicle usage and operational efficiency.
Original PR description
Forward-Port-Of: odoo/odoo#244705
This update resolves a technical issue where a default rate was incorrectly overriding the rate used in delivery FedEx test scenarios. By clearing the existing rate, the tests now accurately reflect the intended rate configurations, ensuring reliable test results. This improves the stability of the delivery FedEx module.
Original PR description
Issue ----- There is some existing rate that takes precedence over the one specified in the test. Rates should be unlinked for safety. ----- Runbot error 237965 Forward-Port-Of: odoo/enterprise#104779
This update fixes a misleading message related to part-time salary calculations. Previously, the system was displaying information based on full-time gross pay, which is no longer accurate due to the change in calculating part-time gross pay. This ensures the system correctly reflects the new part-time salary figures.
Original PR description
Since we are now setting the part-time gross and not the full time gross, this message is misleading. Forward-Port-Of: odoo/enterprise#104877
This update resolves a bug where the link popover would incorrectly appear on input fields within protected nodes. Previously, focusing an input inside a link would trigger the popover. Now, the popover only appears when the input itself is the active element, ensuring a smoother and more predictable user experience when editing content.
Original PR description
Problem: When the previous focus was on a link, then focusing an input inside a non-editable protected node shows the link popover on the input. Cause: Given the following structure: `<a>a</a><span…
Problem: When the previous focus was on a link, then focusing an input inside a non-editable protected node shows the link popover on the input. Cause: Given the following structure: `<a>a</a><span protected non-editable><input></span>` If the selection is inside the link and the link preview popover is visible, clicking on the input triggers a selection change. Since the input is inside a protected node, the editor keeps the previous editable selection. As a result, `LinkPlugin.handleSelectionChange` still treats the selection as being inside the link and reopens the link popover. Solution: Only show the link popover when the `activeElement` is the editable element. Steps to reproduce: - Add a link. - Upload a file. - Place the selection on the link. - Focus the file name input to rename it. - Observe that the link popover is shown on the file name input. opw-5414078 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#240016
This update prevents users from misconfiguring the category snippet within the website builder. Previously, users could unintentionally change the snippet's content to display products or blogs instead of categories, resulting in empty blocks. This fix ensures the snippet functions as intended for category listings.
Original PR description
Steps to reproduce: ==================== 1- Go to any product and in the tab Sales add some accessory products 2- Go to the website and edit a page 3- Add a category list block 4- Change category list filter to "Accessories for product" 5- Save -> The block is empty Cause: ====== The category snippet was meant to be used only for categories. The problem is that its possible to change from "Categories List" to anything else. When the user makes the choice to add a categories snippet he shouldn't be able to change the content of the snippet from categories to products, blogs, etc.. Solution: ========== Prevent replacing the category snippet to anything else. opw-5497284 Forward-Port-Of: odoo/odoo#244053
The picking operations report was incorrectly printing all deliveries on a single page when multiple deliveries were selected. This change addresses a layout update that removed automatic page breaks, now forcing the report to split across multiple pages for better readability and printing. This ensures reports are easier to manage and print effectively.
Original PR description
When printing several picking operation at once, they are all in the same page. Steps to reproduce: ------------------- * Inventory>Operations>Deliveries * Create several Deliveries * Open list view to see all the deliveries * Select several deliveries * Print > Picking Operations -> All the picking operation report are on the same page. Observation: ------------- Since the change on the picking report layout https://github.com/odoo/odoo/pull/152280/changes#diff-7542c191def78bd64f54f1c33fde2c73e19e4d27f92b195c464d1d84e55b682fL6-R8 the report now uses a single article container for all records, this don't trigger automatic page break. opw-5481034 Forward-Port-Of: odoo/odoo#243817
This update enhances the security of user profile editing by utilizing a new internal function, '_can_edit_country()', to determine if a user is authorized to change their country setting. This change, following a previous update, ensures that only permitted users can modify their profile information, improving data integrity and security.
Original PR description
In 'save_edited_profile()', we check that the user can edit his country_id if he tries. As from saas-18.4, a new helper '_can_edit_country()' is available. This commit uses that helper to perform the check. Follow-up of #239789 Task-5331916 Forward-Port-Of: odoo/odoo#244694
This update resolves an issue where registration emails for events were displaying duplicate headers and footers. The fix removed an unnecessary email layout setting that was causing this duplication. This ensures a cleaner and more professional email experience for event attendees.
Original PR description
**Steps to reproduce:** - Go to Event module - Go to an open event - Register for the event - Go to the Attendees of the event - On the attendee record, click `Send by Email` - The received email shows twice the header and footer **Issue:** Encapsulating notification layout was applied with `default_email_layout_xmlid` but the main template used is `event_registration_mail_template_badge` which already has its own header and footer. **Fix:** Removed the `default_email_layout_xmlid` opw-5032767 Forward-Port-Of: odoo/odoo#236667
This update fixes a visual glitch in the spreadsheet edition where the chart's data source selection panel didn't update correctly after linking a datasource. Users could link a datasource, but the interface would still display the previously linked one. This ensures a smoother and more accurate data source selection experience.
Original PR description
Currently, when a user links a chart to an odoo datasource, the sidepanel is not updated properly when the user tries to select a datasource from the same type as the one already selected. How to reproduce: - In a spreadsheet, insert a chart and a list datasource - duplicate the list datasource - in the chart sidepanel, select list#1 as link - now try to select list#2 -> the model update the link to list#2 but the interface still shows list#1. Task-5725964
This update resolves an error that appeared when users set their timezone to "localtime" in Odoo, causing the Avatar card to display an "Invalid DateTime" message. The fix converts "localtime" to the browser's timezone and adds a validation check to ensure time formatting only occurs with valid timezones, improving the user experience.
Original PR description
Purpose of commit: Avatar cards displays “Invalid DateTime local time” when a user’s tz was stored as the literal “localtime”, which Luxon can’t resolve. Add a helper to resolve “localtime” to the browser zone and keep a validity guard so formatting only runs with valid timezones. Steps to reproduce: - Login with user A change the timezone of the user A from the preferences tab. Change it to "localtime" - Login with user B, open avatar card of user A, the below error is shown. <img width="200" height="200" alt="image" src="https://github.com/user-attachments/assets/bd0ad9dd-619f-41dc-bdf1-0a111e2a8862" /> task-5477788
This update resolves a technical issue where assets components were missing from the merged account_batch_payment module. This ensures the module functions correctly and avoids potential performance problems. The fix was implemented as a routine maintenance update.
Original PR description
During the merge of the module account_accountant_batch_payment and account_batch_payment, we forgot to add the components to the assets of the merged module cfr: https://github.com/odoo/enterprise/pull/97544/files#diff-59095aa2812fc8b48436f7aaf3416dc40bb273c7d234ec18a37ac1576d0643e4
A bug preventing the Gantt view from opening has been fixed. This issue occurred when the system couldn't properly access project data, resulting in an error. This update ensures the Gantt view functions correctly for all users.
Original PR description
Currently, an error occurs when the user opens the Gantt view. **Steps to Reproduce:** - Install `timesheet_grid` without demo data. - Go to `Settings` and enable `Project Stages`. - Go to `Projects` and switch to the `Gantt view`. `UnboundLocalError: cannot access local variable 'project' where it is not associated with a value` This error occurs because, in [this commit], line [1] is mistakenly placed outside the loop. If self has no records, project is not defined, and accessing project.date_start raises an error. This commit moves the line inside the loop. [1]: https://github.com/odoo/enterprise/blob/34feeda7d0835d8c65d91493314133b8e83610d1/timesheet_grid/models/project_project.py#L50 [this commit]: https://github.com/odoo/enterprise/commit/c3296d1441400d20e3815207baa1188b5cb8fd93#diff-59e7d75aff5c1e890cd536834137eac5cd3ad185cb45ee1e157be15402cbc90fR50 sentry-7204644855
This update resolves an issue where invoices sent to Viettel's SInvoice system were failing due to incorrect decimal formatting. The change ensures the tax amount is calculated using the currency's rounding rules, preventing these errors and improving invoice processing with SInvoice.
Original PR description
When sending an invoice to SInvoice (Viettel), the API raises an `INVALID_DECIMAL_POINT_TAX_MONEY` error if the tax amount contains excessive decimal places (e.g., 100.02999999999997). This occurs because the tax amount is currently calculated using simple subtraction (`total - subtotal`). Due to standard floating-point precision issues, this can result in unrounded values that the API rejects. The tax amount calculation is now updated to explicitly use the currency's rounding method, ensuring the value is accepted by SInvoice. task-[5484845](https://www.odoo.com/odoo/project/967/tasks/5484845) Forward-Port-Of: odoo/odoo#244647
This update fixes tests related to overtime calculations based on quantity. The changes reflect a recent update to the overtime calculation logic, ensuring the tests accurately reflect the new system. This improves the reliability of our overtime tracking processes.
Original PR description
this PR made some changes to how overtime is calculated by quantity based rules. This PR aims to adapt the test to the new calculation logic Forward-Port-Of: odoo/enterprise#104607
15 changes
Resolved issues and error corrections
This update fixes an issue where product names on invoices were being incorrectly combined, leading to unreadable formatting. The change ensures product names are properly separated with spaces, aligning with API specifications and improving invoice clarity for Vietnam's VAT reporting. This ensures accurate data transmission and compliance.
Original PR description
Before: SInvoice was stripping newlines from the `itemName` field. Since we were directly using `line.name` (which contains a `\n` between product name and description), the content ended up concatenated without any separation. After: Now we replace the newline with a space before sending the value, so the name and description remain readable once processed by SInvoice and set limit to 500 characters as per API specs. task-5498120 Forward-Port-Of: odoo/odoo#243994
This update fixes a test that previously failed inconsistently when marking inbox messages as read after opening a channel. The change ensures the test waits for the initial message fetch, preventing a common scenario where the test incorrectly reports a failure. This improves the stability and reliability of the inbox read functionality.
Original PR description
The `Opening thread with needaction messages should mark all messages of thread as read` ensures that opening a channel marks the related inbox messages as read. However, this test can fail in a non-deterministic fashion. There are two flows that can mark inbox messages as read: fetching the messages or a manual request after opening the channel. The test expects the rpc to be issued, but if the messages are fetched before, it won't happen thus making the test fail. This commit awaits the initial fetch to prevent this issue. As a bonus, the second flow is also tested. runbot-237970 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#244693
This update strengthens the way Odoo handles errors during file uploads. Previously, the file upload service struggled with inconsistent responses from Odoo controllers (which could return data in different formats). Now, the service is better equipped to manage these errors, leading to a more stable and reliable file upload experience for users.
Original PR description
Odoo controllers often don't use coherent API they respond with either json, jsonrpc or html. On the client side, we have no reliable way to know this, and sometimes it is not possible to make a guess (rpc.js makes the guess that controllers are of json type -- actually meaning jsonrpc) The file upload service suffered from this and did not handle those error cases well. After this commit, the file upload service handles much of the errors. 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#244704
This update fixes an issue where Odoo was creating duplicate vendor contacts due to differences in how VAT numbers were formatted. Now, Odoo will correctly identify and link invoices with the same VAT number, regardless of whether the name or VAT number format includes dots. This ensures accurate record-keeping and reporting.
Original PR description
Description of the issue/feature this PR addresses: Odoo can create two contacts for the same VAT number Current behavior before PR: If you have two incoming vendor bills (over a period of time)…
Description of the issue/feature this PR addresses: Odoo can create two contacts for the same VAT number Current behavior before PR: If you have two incoming vendor bills (over a period of time) where the first bill has these details: - VAT number: `BE0477472701` - Name: `Odoo` And the second bill (e.g three months later) has these details: - VAT number: `BE0477.472.701` - Name: `Odoo S.A` Odoo will do something interesting and will create a second new contact. The reason is because the fallback on `name` from `res.partner` fails (since "Odoo S.A" is not equal to "Odoo". However, the `vat` number matching also fails! Since the VAT number "BE0477.472.701" is not identical to "BE0477472701". Throughout Odoo however VAT numbers are parsed and stored without dots in it. The function `_retrieve_partner_with_vat` however is an exception because the `vat` number here is sanitized for spaces but not for dots. Because of the combination of no exact match on neither `name` nor `vat` it now creates a second contact although the VAT number is technically the same. Desired behavior after PR is merged: Both an incoming vendor bill with `0477.472.701` and `0477472701` match to the same contact even if there are dots in it and if the name of the company is different. P.S: please find two sample XML's here: [sample_odoo_sa_bill.xml](https://github.com/user-attachments/files/24718225/sample_odoo_sa_bill.xml) [sample_odoo_bill.xml](https://github.com/user-attachments/files/24718226/sample_odoo_bill.xml) If you upload both back to back on a default V19 you will see two contacts. After this code change you will only see one contact where both bills are mapped to the same contacts. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244572
This update fixes an issue where employee names were being incorrectly formatted in payroll reports. The change ensures that employee names are consistently displayed as 'FirstName LastName', aligning with Swiss legal requirements and improving data accuracy for payroll processing. The fix also includes updated test data to reflect this corrected format.
Original PR description
* Fix _compute_l10n_ch_legal_name method to correctly assign first_name and last_name from employee name (was previously reversed) * Update all SwissDEC test data to use correct "FirstName LastName" format instead of "LastName FirstName" to match the corrected computation logic task-5102851 Forward-Port-Of: odoo/enterprise#95252
This update resolves an issue where accessing settings in the Romanian language version of Odoo resulted in an error. The fix corrects a mismatch in text matching within the system's configuration views, ensuring proper functionality for Romanian users. This improves the user experience for Romanian-speaking clients.
Original PR description
**Issue**: When the module `l10n_ro_edi_stock` is installed and Romanian is the selected language, accessing the settings app causes a traceback. **Steps to reproduce**: - Install the module…
**Issue**: When the module `l10n_ro_edi_stock` is installed and Romanian is the selected language, accessing the settings app causes a traceback. **Steps to reproduce**: - Install the module `l10n_ro_edi_stock` - Select a Romanian company - In Profile > My Preferences > select Romanian language - Try to access the settings -> A traceback occurs **Cause**: The error is caused by this XPath: https://github.com/odoo/odoo/blob/2309fb56553e6ae9f89b6dd0947aba2f54408960/addons/l10n_ro_edi_stock/views/res_config_settings_views.xml#L9C13-L11C21 Specifically, the `'select the option'` part. The XPath tries to replace this line in the parent view: https://github.com/odoo/odoo/blob/2309fb56553e6ae9f89b6dd0947aba2f54408960/addons/l10n_ro_edi/views/res_config_settings_views.xml#L39 but fails to find it because the source text has already been translated at that point, so `'select the option'` no longer matches: https://github.com/odoo/odoo/blob/2309fb56553e6ae9f89b6dd0947aba2f54408960/odoo/tools/template_inheritance.py#L154 **Solution** Only rely on strings that are translation-invariant. opw-5490346 Forward-Port-Of: odoo/odoo#244313
This update ensures that optional product images are only shown when the system is configured to display them. Previously, images were always shown, even when disabled, leading to a cluttered UI. Now, a placeholder is used when no image is available, providing a cleaner and more consistent experience.
Original PR description
Before this commit: =================== - When the `Show product images` setting was disabled, the optional products UI still displayed product images. - If an optional product did not have an image, the UI displayed the image's alt text - Also when the product don't have image, the combo popup and product card just display the product name. After this commit: ================== - Optional product images are displayed only when the `Show product images` configuration is enabled. - If the optional product doesn't have an image, we will display an image placeholder instead of alt text. - If there is no product image, the combo popup and product card will display the image placeholder. Task: 5480181 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243222
This update fixes an issue where the cookie consent wasn't being saved correctly when the 'I agree' button style was changed to 'Default'. The change triggered a default behavior in the popup system, preventing the consent from being recorded. This ensures that user cookie consent is properly saved after customizing the cookie bar's appearance.
Original PR description
Steps to reproduce: =================== 1. Enable the Cookies Bar in website settings. 2. Go to the website and enter Edit mode. 3. Select the Cookie Bar and change the button "I agree" style shape…
Steps to reproduce: =================== 1. Enable the Cookies Bar in website settings. 2. Go to the website and enter Edit mode. 3. Select the Cookie Bar and change the button "I agree" style shape to "Default" (this applies the `.btn-primary` class). & Save 4. Accept the cookies & refresh -> The cookie bar appears again because the consent was not saved. Cause: ====== The `CookiesBar` widget inherits from the generic `Popup` widget. The `Popup` class defines a default behavior for elements with the `.btn-primary` class: clicking them triggers `onBtnPrimaryClick`, which closes the popup. By default, the cookie bar button uses `.btn-outline-primary`, avoiding this behavior. However, when the user changes the style to "Default", the button receives the `.btn-primary` class. Consequently, the parent `Popup` handler is triggered. It closes the modal prematurely, interrupting the `CookiesBar`'s specific logic (specifically `onAcceptClick`),So onHideModal won't be called inside the function, and as a result, the user's consent cookie is never written. Solution: ========= Override the event to avoid side effects on hide. opw-5484578 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243562
This update resolves a technical issue that was preventing the employee version timeline from automatically saving correctly. The fix involved updating the test code to use a method that simulates a consistent time environment, ensuring data is saved reliably. This improves the stability and accuracy of employee version tracking.
Original PR description
As runbot faketimes test fail because the usage of dynamic dates now the test uses freeze_time Task#5717031 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where importing invoices could halt the entire process if one invoice encountered an error. Previously, failing on a single invoice would cause duplicate invoices to be created. This change ensures that the import process continues smoothly even if individual invoices have problems, improving data accuracy and reliability.
Original PR description
When you import a batch of invoice and one of them gets an unexpected Exception, the others are created but we stop the method. It's a problem with crons that don't expect to be interrupted in the middle. It creates duplicates as we fail on the same invoice each time. Of course, we should avoid all Exceptions when we can, but we should not loop on the same error. opw-5503069 part of task-5499871 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where multiple delivery reports were printed on the same page. The change in the report layout prevented automatic page breaks, causing reports with multiple deliveries to be combined. This ensures that reports with multiple deliveries are formatted correctly for printing.
Original PR description
When printing several picking operation at once, they are all in the same page. Steps to reproduce: ------------------- * Inventory>Operations>Deliveries * Create several Deliveries * Open list view to see all the deliveries * Select several deliveries * Print > Picking Operations -> All the picking operation report are on the same page. Observation: ------------- Since the change on the picking report layout https://github.com/odoo/odoo/pull/152280/changes#diff-7542c191def78bd64f54f1c33fde2c73e19e4d27f92b195c464d1d84e55b682fL6-R8 the report now uses a single article container for all records, this don't trigger automatic page break. opw-5481034 Forward-Port-Of: odoo/odoo#243817
This update resolves an issue where registration emails for events were displaying duplicate headers and footers. The fix removed a redundant email layout setting, ensuring that only the event's standard header and footer are included in the sent emails. This improves the email experience for registered users.
Original PR description
**Steps to reproduce:** - Go to Event module - Go to an open event - Register for the event - Go to the Attendees of the event - On the attendee record, click `Send by Email` - The received email shows twice the header and footer **Issue:** Encapsulating notification layout was applied with `default_email_layout_xmlid` but the main template used is `event_registration_mail_template_badge` which already has its own header and footer. **Fix:** Removed the `default_email_layout_xmlid` opw-5032767 Forward-Port-Of: odoo/odoo#236667
This update ensures popover animations in our tests run consistently, preventing unexpected behavior and reducing test complexity. A fix was implemented to address timing issues and enable the ResizeObserver, improving the reliability of our test suite. This enhances the stability of the web application.
Original PR description
This commit fixes two things; 1. Because the popover had his animation enabled in tests, it could on very rare occasion end too fast and call it's finished callback, triggering extra repositionning (and thus extra expect.steps). 2. The ResizeObserver could never trigger if there where no animations, it now can but some tests had to be adapted. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where the IoT driver was adding unnecessary IDs to the system, slowing down performance when actions took longer than 6 seconds. The fix ensures IDs are only added to the cache when actions complete successfully, optimizing the driver's responsiveness and reducing potential bottlenecks.
Original PR description
If an action takes a long time to execute (>6s), then we don't add the unique id during this time as the action didn't finish. As it exceeds 6 seconds, we also send one through websocket, that isn't filtered as duplicate as the action id isn't set yet in the `_recent_action_ids` cache. To avoid this, we add the action id to the cache, then execute the action and remove the id from the cache if there is an exception.
This update resolves an issue where invoices sent to the Viettel SInvoice system were failing due to incorrect tax amount formatting. The change ensures the tax amount is calculated using the currency's rounding method, aligning with SInvoice's requirements and preventing errors.
Original PR description
When sending an invoice to SInvoice (Viettel), the API raises an `INVALID_DECIMAL_POINT_TAX_MONEY` error if the tax amount contains excessive decimal places (e.g., 100.02999999999997). This occurs because the tax amount is currently calculated using simple subtraction (`total - subtotal`). Due to standard floating-point precision issues, this can result in unrounded values that the API rejects. The tax amount calculation is now updated to explicitly use the currency's rounding method, ensuring the value is accepted by SInvoice. task-[5484845](https://www.odoo.com/odoo/project/967/tasks/5484845) Forward-Port-Of: odoo/odoo#244647
6 changes
Resolved issues and error corrections
This update fixes an issue where Odoo was creating duplicate contacts for vendor bills with slightly different VAT number formats (with or without dots). Now, Odoo will correctly identify and link bills with the same VAT number, regardless of formatting, ensuring accurate record-keeping and reporting. This improves data consistency and simplifies reconciliation processes.
Original PR description
Description of the issue/feature this PR addresses: Odoo can create two contacts for the same VAT number Current behavior before PR: If you have two incoming vendor bills (over a period of time)…
Description of the issue/feature this PR addresses: Odoo can create two contacts for the same VAT number Current behavior before PR: If you have two incoming vendor bills (over a period of time) where the first bill has these details: - VAT number: `BE0477472701` - Name: `Odoo` And the second bill (e.g three months later) has these details: - VAT number: `BE0477.472.701` - Name: `Odoo S.A` Odoo will do something interesting and will create a second new contact. The reason is because the fallback on `name` from `res.partner` fails (since "Odoo S.A" is not equal to "Odoo". However, the `vat` number matching also fails! Since the VAT number "BE0477.472.701" is not identical to "BE0477472701". Throughout Odoo however VAT numbers are parsed and stored without dots in it. The function `_retrieve_partner_with_vat` however is an exception because the `vat` number here is sanitized for spaces but not for dots. Because of the combination of no exact match on neither `name` nor `vat` it now creates a second contact although the VAT number is technically the same. Desired behavior after PR is merged: Both an incoming vendor bill with `0477.472.701` and `0477472701` match to the same contact even if there are dots in it and if the name of the company is different. P.S: please find two sample XML's here: [sample_odoo_sa_bill.xml](https://github.com/user-attachments/files/24718225/sample_odoo_sa_bill.xml) [sample_odoo_bill.xml](https://github.com/user-attachments/files/24718226/sample_odoo_bill.xml) If you upload both back to back on a default V19 you will see two contacts. After this code change you will only see one contact where both bills are mapped to the same contacts. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244572
This update resolves an issue where accessing settings in the Romanian language version of the l10n_ro_edi_stock module resulted in an error. The fix ensures that settings can be accessed correctly when the Romanian language is selected for a company, improving usability for Romanian-speaking users.
Original PR description
**Issue**: When the module `l10n_ro_edi_stock` is installed and Romanian is the selected language, accessing the settings app causes a traceback. **Steps to reproduce**: - Install the module…
**Issue**: When the module `l10n_ro_edi_stock` is installed and Romanian is the selected language, accessing the settings app causes a traceback. **Steps to reproduce**: - Install the module `l10n_ro_edi_stock` - Select a Romanian company - In Profile > My Preferences > select Romanian language - Try to access the settings -> A traceback occurs **Cause**: The error is caused by this XPath: https://github.com/odoo/odoo/blob/2309fb56553e6ae9f89b6dd0947aba2f54408960/addons/l10n_ro_edi_stock/views/res_config_settings_views.xml#L9C13-L11C21 Specifically, the `'select the option'` part. The XPath tries to replace this line in the parent view: https://github.com/odoo/odoo/blob/2309fb56553e6ae9f89b6dd0947aba2f54408960/addons/l10n_ro_edi/views/res_config_settings_views.xml#L39 but fails to find it because the source text has already been translated at that point, so `'select the option'` no longer matches: https://github.com/odoo/odoo/blob/2309fb56553e6ae9f89b6dd0947aba2f54408960/odoo/tools/template_inheritance.py#L154 **Solution** Only rely on strings that are translation-invariant. opw-5490346 Forward-Port-Of: odoo/odoo#244313
This update resolves an issue where multiple delivery reports were printed on the same page. The change in the report layout prevented automatic page breaks, causing reports with multiple deliveries to be combined. This ensures that all picking operations are displayed on separate pages for easier printing and readability.
Original PR description
When printing several picking operation at once, they are all in the same page. Steps to reproduce: ------------------- * Inventory>Operations>Deliveries * Create several Deliveries * Open list view to see all the deliveries * Select several deliveries * Print > Picking Operations -> All the picking operation report are on the same page. Observation: ------------- Since the change on the picking report layout https://github.com/odoo/odoo/pull/152280/changes#diff-7542c191def78bd64f54f1c33fde2c73e19e4d27f92b195c464d1d84e55b682fL6-R8 the report now uses a single article container for all records, this don't trigger automatic page break. opw-5481034 Forward-Port-Of: odoo/odoo#243817
A bug in the demo test setup was preventing it from correctly accessing necessary user permissions. This fix ensures the test accurately simulates real user access, specifically addressing a failure when testing the 'Overdue Customer Invoices' filter. The update adds the required access groups to the demo user, resolving the test failure.
Original PR description
__Steps to reproduce:__ 1. Create a new db with `contacts` and `account_followup` installed without demo data. 2. Run `TestMenusDemo` using `--test-tags click_all:TestMenusDemo`. => It fails when testing the "Overdue Customer Invoices" filter. __Reason:__ `TestMenusDemo` inherits from `HttpCaseWithUserDemo`, which creates a fake user demo if the database does not already contain one (meaning that it has no demo data). However, when doing so, it does not include all the access groups needed by the different modules. Since this filter requires access to `account.move.line`, an `AccessError` is raised and the test fails. __Fix:__ - Inside `TransactionCaseWithUserDemo` setup, add all the access groups in which Marc Demo normally is included to better represent the real flow. - Clean up the duplicate code. runbot-231045
This update resolves an issue where registration emails for events were displaying duplicate headers and footers. The fix removed a redundant email layout setting that was causing this duplication. This ensures a cleaner and more professional email experience for event attendees.
Original PR description
**Steps to reproduce:** - Go to Event module - Go to an open event - Register for the event - Go to the Attendees of the event - On the attendee record, click `Send by Email` - The received email shows twice the header and footer **Issue:** Encapsulating notification layout was applied with `default_email_layout_xmlid` but the main template used is `event_registration_mail_template_badge` which already has its own header and footer. **Fix:** Removed the `default_email_layout_xmlid` opw-5032767 Forward-Port-Of: odoo/odoo#236667
This update automatically adjusts the start and end dates for salary certificate reporting in Odoo's Swiss localization module (l10n_ch_hr_payroll). Previously, these dates were static, now they dynamically pull from the configured data, ensuring accurate reporting for Swiss businesses. This change simplifies the process and reduces the risk of errors.
Original PR description
make Period until and from dynamic from data Forward-Port-Of: odoo/enterprise#104903
7 changes
Resolved issues and error corrections
This update fixes an issue where product names on invoices were being incorrectly combined, leading to unreadable output. The change adds a space to separate the name and description, ensuring invoices comply with API specifications and maintain clear formatting for the Vietnam VAT reporting process. This improves data accuracy and readability.
Original PR description
Before: SInvoice was stripping newlines from the `itemName` field. Since we were directly using `line.name` (which contains a `\n` between product name and description), the content ended up concatenated without any separation. After: Now we replace the newline with a space before sending the value, so the name and description remain readable once processed by SInvoice and set limit to 500 characters as per API specs. task-5498120 Forward-Port-Of: odoo/odoo#243994
This update fixes an issue where VAT import taxes were incorrectly generating journal entries due to a change in account settings. The fix updates the default account used for taxes tax_purchase_import_10, tax_purchase_import_8, and tax_purchase_import_5, ensuring accurate financial reporting.
Original PR description
Due to the change of account 33312 from liability to payable, the journal entries generated when creating bills with VAT import taxes were incorrect. This fix updates the default account on the following taxes: - tax_purchase_import_10 - tax_purchase_import_8 - tax_purchase_import_5 task-5695253 Forward-Port-Of: odoo/odoo#244434
This update fixes an issue where Odoo was creating duplicate vendor contacts when receiving invoices with slightly different VAT number formats (with or without dots). Now, invoices with the same VAT number, even with variations in formatting, will always be linked to the same contact, streamlining our accounting processes.
Original PR description
Description of the issue/feature this PR addresses: Odoo can create two contacts for the same VAT number Current behavior before PR: If you have two incoming vendor bills (over a period of time)…
Description of the issue/feature this PR addresses: Odoo can create two contacts for the same VAT number Current behavior before PR: If you have two incoming vendor bills (over a period of time) where the first bill has these details: - VAT number: `BE0477472701` - Name: `Odoo` And the second bill (e.g three months later) has these details: - VAT number: `BE0477.472.701` - Name: `Odoo S.A` Odoo will do something interesting and will create a second new contact. The reason is because the fallback on `name` from `res.partner` fails (since "Odoo S.A" is not equal to "Odoo". However, the `vat` number matching also fails! Since the VAT number "BE0477.472.701" is not identical to "BE0477472701". Throughout Odoo however VAT numbers are parsed and stored without dots in it. The function `_retrieve_partner_with_vat` however is an exception because the `vat` number here is sanitized for spaces but not for dots. Because of the combination of no exact match on neither `name` nor `vat` it now creates a second contact although the VAT number is technically the same. Desired behavior after PR is merged: Both an incoming vendor bill with `0477.472.701` and `0477472701` match to the same contact even if there are dots in it and if the name of the company is different. P.S: please find two sample XML's here: [sample_odoo_sa_bill.xml](https://github.com/user-attachments/files/24718225/sample_odoo_sa_bill.xml) [sample_odoo_bill.xml](https://github.com/user-attachments/files/24718226/sample_odoo_bill.xml) If you upload both back to back on a default V19 you will see two contacts. After this code change you will only see one contact where both bills are mapped to the same contacts. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244572
This update resolves an issue where accessing settings was blocked when the l10n_ro_edi_stock module was used with the Romanian language selected. The fix corrects a mismatch in the system's text search, ensuring settings are accessible for Romanian users. This improves usability for Romanian-speaking customers.
Original PR description
**Issue**: When the module `l10n_ro_edi_stock` is installed and Romanian is the selected language, accessing the settings app causes a traceback. **Steps to reproduce**: - Install the module…
**Issue**: When the module `l10n_ro_edi_stock` is installed and Romanian is the selected language, accessing the settings app causes a traceback. **Steps to reproduce**: - Install the module `l10n_ro_edi_stock` - Select a Romanian company - In Profile > My Preferences > select Romanian language - Try to access the settings -> A traceback occurs **Cause**: The error is caused by this XPath: https://github.com/odoo/odoo/blob/2309fb56553e6ae9f89b6dd0947aba2f54408960/addons/l10n_ro_edi_stock/views/res_config_settings_views.xml#L9C13-L11C21 Specifically, the `'select the option'` part. The XPath tries to replace this line in the parent view: https://github.com/odoo/odoo/blob/2309fb56553e6ae9f89b6dd0947aba2f54408960/addons/l10n_ro_edi/views/res_config_settings_views.xml#L39 but fails to find it because the source text has already been translated at that point, so `'select the option'` no longer matches: https://github.com/odoo/odoo/blob/2309fb56553e6ae9f89b6dd0947aba2f54408960/odoo/tools/template_inheritance.py#L154 **Solution** Only rely on strings that are translation-invariant. opw-5490346 Forward-Port-Of: odoo/odoo#244313
This update prevents excessive email notifications to managers when employees submit expenses. Previously, every state change triggered an email, leading to potential spam. Now, a weekly email is still sent to managers if they have pending expenses, streamlining the approval process and improving user experience.
Original PR description
When an employee submits an expense and assigns a manager, an approval activity is scheduled. However, email notifications are now disabled to avoid spamming the assigned managers. * Prevent notifying the expense manager when expense state changes. * Email 'Next expense is waiting your approval' is scheduled to be sent to the manager once a week if the manager has any expenses left to approve. task-4676396 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where registration emails for events were displaying duplicate headers and footers. The fix removed a redundant email layout setting, ensuring consistent and correct email formatting for attendees. This improves the overall user experience and email deliverability.
Original PR description
**Steps to reproduce:** - Go to Event module - Go to an open event - Register for the event - Go to the Attendees of the event - On the attendee record, click `Send by Email` - The received email shows twice the header and footer **Issue:** Encapsulating notification layout was applied with `default_email_layout_xmlid` but the main template used is `event_registration_mail_template_badge` which already has its own header and footer. **Fix:** Removed the `default_email_layout_xmlid` opw-5032767 Forward-Port-Of: odoo/odoo#236667
This update removes a previous fix for the website slides module, which was no longer needed due to recent changes. This streamlines the code and prevents duplication, ensuring a more efficient and stable user experience for customers.
Original PR description
Following the changes in PR #236475, the fix in PR #232696 is no longer required. This commit reverts commit 4c02c970ed824e2b1ade90b905365519044abc69, ensuring that the fix remains within the portal_rating module and preventing duplicate code for the same issue. This change should be forward ported up to saas-18.2. For later versions, the revert is already handled in PR #243783. Forward-Port-Of: odoo/odoo#244057
25 changes
Resolved issues and error corrections
This update prevents the HTML Builder editor from freezing due to rare errors within its internal processes. A timeout mechanism is now in place to release the editor and alert the user to potential data issues, ensuring a smoother user experience. The change also includes safeguards to prevent long-running operations from causing problems.
Original PR description
Before this commit, if an error occurred within the mutex that did not explicitly throw, the mutex could remain locked indefinitely. This blocked subsequent actions and prevented the user from saving. This commit introduces a timeout mechanism for Operations. This is intended for very rare cases as a last resort to prevent the editor from becoming completely unresponsive. When a timeout occurs: - The mutex is released, allowing the user to recover (e.g. by deleting the faulty snippet). - The user is notified of the issue. - A warning is displayed during saving to indicate that the content might be in a corrupted state. Additionally, the `canTimeout: false` flag is added to options that are expected to remain open for long periods (such as the snippet modal). task-5152911 Forward-Port-Of: odoo/odoo#244786 Forward-Port-Of: odoo/odoo#233079
This update removes a redundant 'OK' button from form dialogs within the Point of Sale system. Previously, this change only applied when the 'pos_appointment' module was active. Now, the change is applied consistently across all POS form dialogs, improving the user experience and ensuring a uniform design.
Original PR description
Before this commit: =================== - The extra `OK` button in form view dialogs was removed only when the `pos_appointment` module was installed. After this commit: ================== - The CSS to remove the extra `OK` button has been moved from `pos_appointment` to the base `point_of_sale` module, ensuring consistent behavior across POS form dialogs. Task:5406858 Related Enterprise PR: https://github.com/odoo/enterprise/pull/102197 Forward-Port-Of: odoo/odoo#240165
This update removes a redundant 'OK' button from POS form dialogs, ensuring a cleaner and more consistent user experience across all Point of Sale operations. The change was made to standardize the styling, previously only applied when the 'pos_appointment' module was installed.
Original PR description
Before this commit: =================== - The extra `OK` button in form view dialogs was removed only when the `pos_appointment` module was installed. After this commit: ================== - The CSS to remove the extra `OK` button has been moved from `pos_appointment` to the base `point_of_sale` module, ensuring consistent behavior across POS form dialogs. Task: 5406858 Related Community PR: https://github.com/odoo/odoo/pull/240165 Forward-Port-Of: odoo/enterprise#102197
This update resolves an issue where the website editor could become unreliable when creating new pages under slower network conditions. The fix ensures the editor only opens after the iframe has fully loaded, resulting in a more consistent and dependable editing experience. This improves the overall usability of the website builder.
Original PR description
Steps to reproduce: 1. Set network speed to 3G 2. Create website Page from the systry new menu 3. click on edit button You'll face the traceback. The website editor could try to open before the iframe finished loading, leading to non-deterministic behavior. This commit ensures the editor initializes only after the iframe load event, making the edit action consistent and reliable. Erlier fixed was not covering the all the cases. PR: https://github.com/odoo/odoo/pull/238054 runbot-233039 Forward-Port-Of: odoo/odoo#243256
This pull request resolves a minor issue with the demo functionality within the Quality Control module. The changes ensure the demo runs correctly and provides a functional example for users. This improves the usability and clarity of the Quality Control module's demonstration.
Original PR description
demo
This update resolves an issue preventing localized date/time intervals within the appointment scheduling feature. The fix now correctly localizes only the start and end times of intervals, ensuring accurate display across different locales. This improves the user experience for scheduling appointments in various languages.
Original PR description
Following this refactor PR: https://github.com/odoo/enterprise/pull/96139, the localized method could not be applied to the whole interval object as it contains a model. This commit fixes the issue by localizing only the start and end of the interval. Runbot build error: https://runbot.odoo.com/odoo/runbot.build.error/238001
This update resolves a crash that occurred when grouping data in list views using floating-number fields with the 'monetary' widget. The fix ensures the system handles missing currency information gracefully, preventing aggregation errors and improving the stability of list views. This enhances the reliability of reporting and data analysis.
Original PR description
This commit resolves a traceback during list view aggregation when the view is grouped. The crash occurred specifically when aggregating a `float` field that uses the `monetary` widget. Unlike true `monetary` fields, the server does not automatically send a `currency_id` aggregate for `float` fields. The aggregation logic previously failed when this data was missing; it now handles the case by ignoring it since it's not supported. opw-5725692 Forward-Port-Of: odoo/odoo#244548
This update resolves an issue where a test for marking inbox messages as read would intermittently fail due to the order in which messages were processed. The change ensures the initial fetch of messages occurs first, guaranteeing the expected test outcome. This improves the reliability of the inbox read functionality.
Original PR description
The `Opening thread with needaction messages should mark all messages of thread as read` ensures that opening a channel marks the related inbox messages as read. However, this test can fail in a non-deterministic fashion. There are two flows that can mark inbox messages as read: fetching the messages or a manual request after opening the channel. The test expects the rpc to be issued, but if the messages are fetched before, it won't happen thus making the test fail. This commit awaits the initial fetch to prevent this issue. As a bonus, the second flow is also tested. runbot-237970 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#244693
This update fixes an issue where the Odoo Studio export process incorrectly excluded certain related and computed fields. The team refined the logic to handle these fields separately, ensuring a more accurate export of data. The Industry team has approved these changes.
Original PR description
This commit fixes the computation of excluded fields for the studio export models. Before this commit, the excluded fields computation was considering computed and related fields in a similar way but…
This commit fixes the computation of excluded fields for the studio export models. Before this commit, the excluded fields computation was considering computed and related fields in a similar way but there are subtle differences that cause the excluded fields to sometimes be wrong. While analyzing the heuristic with the ORM team, we decided to separate the computation of related and computed fields. After this commit, we have a refined computation of excluded fields for related and computed fields: - for computed fields (that are not related ones), we always exclude them except when they are writeable (i.e. stored or with inverse) - for related fields, we always exclude them when the relation is in the list of related models to exclude. We also exclude them when they are not writeable on the current record only (not the source record), except if they are required. Some export scenarios have been tested manually and brought with them adaptations in the hardcoded lists of default fields to exclude. The Industry team agreed with these changes. Task id: opw-4974787 Forward-Port-Of: odoo/enterprise#104780 Forward-Port-Of: odoo/enterprise#87530
A recent issue prevented users from using the database obfuscation command. This update corrects a technical error where the command was incorrectly processing database names, resulting in an error. Now, the obfuscate command functions as intended, ensuring data protection.
Original PR description
It is not possible to use the obfuscate command Steps to reproduce: 1. Initialize a database `test` 2. In a terminal, try to obfuscate the database with the command `python odoo/odoo-bin obfuscate --pwd=1234 -d test` 3. An error occurs Issue: `config['db_name']` returns a list Solution: Make sure we use obfuscate with a single database and get the first (and only) database in the list opw-5480280 Forward-Port-Of: odoo/odoo#244577
This update resolves an issue where scanning cashier barcodes would cause an error if employee logging was turned off. Now, the barcode scanning functionality works as expected regardless of whether employee logging is enabled, ensuring a smoother checkout experience for users. This change improves reliability and prevents disruptions during transactions.
Original PR description
Before this commit, if logging with employee was disabled, scanning a cashier barcode would raise an error. opw-5437310 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241756 Forward-Port-Of: odoo/odoo#241131
This update enhances how Odoo's spreadsheet feature retrieves cell data. Previously, data was organized as an object, but now it's returned as a simple array, making it easier for the spreadsheet to process and display information. This change improves the overall performance and reliability of the spreadsheet functionality.
Original PR description
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 resolves a test case issue related to creating public leave in Odoo. Specifically, the system now correctly passes the company information during leave creation, preventing errors that could occur due to conflicting work entries. This ensures accurate public leave functionality.
Original PR description
In this PR, We are explicitly passing the company to create a public leave Task-4596057
This update resolves a crash that occurred when users accessed the Gantt Overview within the Time Off application. The fix involved adjustments to how unavailable time periods are handled, ensuring data integrity and stability during Gantt rendering. This improves the reliability of the Time Off module.
Original PR description
Version: - saas-19.2 Steps to reproduce: - Install hr_holidays_gantt - Open the Time Off application - Click on the Overview menu item Issue: - A server traceback occurs when loading the Gantt Overview. Solution: - Adapt _gantt_unavailability() to handle the new return structure of _unavailable_intervals_batch(), which now returns multiple intervals per resource. - Ensure all datetime comparisons are performed using timezone-aware UTC datetimes by converting contract dates with fields.Datetime.to_datetime(). - Properly append unavailable intervals as (start, stop) tuples to avoid data corruption during Gantt rendering. Task- 5702559
This update corrects a visual bug where an 'Add Item' button incorrectly remained visible when no topics were present in a web page snippet. The fix ensures the button disappears when there are no topics, preventing a traceback and improving the user experience. This change impacts the Topics List snippet and related website builder components.
Original PR description
Steps to reproduce: - Drag and drop a "Topics List" snippet onto a web page. - Remove all "Topic" items from the snippet so that none remain. - Click the "Add New" button. - A traceback occurs. This bug is caused by the fact that the "Add item" option is defined in the "Options" section of the parent element of the topics. As a result, the option button remains visible even when no topics exist anymore. Clicking it then triggers a traceback because the option attempts to duplicate an element that does not exist. In this commit, we fix the issue by adding an "applyTo" on the option, targeting the topics, so that the "Add New" button no longer appears when no topic is present. Note that the same bug exists for other snippets, and this commit fixes them as well. task-5462596 Forward-Port-Of: odoo/odoo#244126 Forward-Port-Of: odoo/odoo#244034
This update resolves a technical issue preventing users with the Romanian language pack installed from accessing the settings within the l10n_ro_edi_stock module. The fix corrects a mismatch in the system's text search, ensuring proper functionality for Romanian users. This improves the usability of the module for Romanian-speaking businesses.
Original PR description
**Issue**: When the module `l10n_ro_edi_stock` is installed and Romanian is the selected language, accessing the settings app causes a traceback. **Steps to reproduce**: - Install the module…
**Issue**: When the module `l10n_ro_edi_stock` is installed and Romanian is the selected language, accessing the settings app causes a traceback. **Steps to reproduce**: - Install the module `l10n_ro_edi_stock` - Select a Romanian company - In Profile > My Preferences > select Romanian language - Try to access the settings -> A traceback occurs **Cause**: The error is caused by this XPath: https://github.com/odoo/odoo/blob/2309fb56553e6ae9f89b6dd0947aba2f54408960/addons/l10n_ro_edi_stock/views/res_config_settings_views.xml#L9C13-L11C21 Specifically, the `'select the option'` part. The XPath tries to replace this line in the parent view: https://github.com/odoo/odoo/blob/2309fb56553e6ae9f89b6dd0947aba2f54408960/addons/l10n_ro_edi/views/res_config_settings_views.xml#L39 but fails to find it because the source text has already been translated at that point, so `'select the option'` no longer matches: https://github.com/odoo/odoo/blob/2309fb56553e6ae9f89b6dd0947aba2f54408960/odoo/tools/template_inheritance.py#L154 **Solution** Only rely on strings that are translation-invariant. opw-5490346 Forward-Port-Of: odoo/odoo#244313
This update corrects a calculation error in the fleet module related to the initial acquisition date of vehicles. By setting a default acquisition date, the system now accurately calculates baseline ATN (Asset Tracking Net) values, leading to more precise reporting and financial tracking of fleet assets. This ensures better data for business decisions related to vehicle depreciation and asset management.
Original PR description
Forward-Port-Of: odoo/odoo#244705
This update resolves a technical issue where a default rate was incorrectly overriding the rate used in testing for FedEx deliveries in the EUR currency. By clearing these outdated rates, the test environment now accurately reflects the intended pricing, ensuring reliable testing and accurate delivery calculations.
Original PR description
Issue ----- There is some existing rate that takes precedence over the one specified in the test. Rates should be unlinked for safety. ----- Runbot error 237965 Forward-Port-Of: odoo/enterprise#104779
This update ensures the minimum wage is accurately calculated and pro-rated based on employee work time. The change addresses a previous issue (302bf2b4e201da8f56b1da012dd7f03c81a85e22) to comply with Belgian labor laws, improving payroll accuracy.
Original PR description
Since changes made in 302bf2b4e201da8f56b1da012dd7f03c81a85e22 the minimum wage should be pro-rated to the work time rate. Forward-Port-Of: odoo/enterprise#104781 Forward-Port-Of: odoo/enterprise#104419
This update resolves intermittent failures in image edit tests within the Odoo website builder. These tests were failing due to delays in how the website builder's sidebar updates asynchronously. By adding a 'wait' function to ensure the sidebar is fully loaded before tests run, we've significantly improved test reliability and stability.
Original PR description
Image edit tests using the builder sidebar were failing intermittently because image elements rely on async actions with non-deterministic timing, causing the sidebar options to be unavailable sometimes. Use `waitSidebarUpdated` to ensure the sidebar is fully updated before asserting on its content. Here is an example of an error: error-234951 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#243343 Forward-Port-Of: odoo/odoo#243008
This update prevents users from incorrectly configuring a website category snippet to display product accessories instead of categories. The change ensures that the snippet functions as intended, displaying relevant category lists on product pages. This resolves an issue where the category snippet was producing empty results.
Original PR description
Steps to reproduce: ==================== 1- Go to any product and in the tab Sales add some accessory products 2- Go to the website and edit a page 3- Add a category list block 4- Change category list filter to "Accessories for product" 5- Save -> The block is empty Cause: ====== The category snippet was meant to be used only for categories. The problem is that its possible to change from "Categories List" to anything else. When the user makes the choice to add a categories snippet he shouldn't be able to change the content of the snippet from categories to products, blogs, etc.. Solution: ========== Prevent replacing the category snippet to anything else. opw-5497284 Forward-Port-Of: odoo/odoo#244053
This update resolves a sporadic issue where live chat sessions would unexpectedly crash. The fix addresses a timing conflict between guest leaving and chat closing, preventing a system error. This ensures a more reliable and consistent live chat experience for users.
Original PR description
This commit fixes the `visitor leaving ends the livechat conversation` test that was sometimes failing. There is a race between the simulation of the guest leaving the chat that uses `withGuest` which is known to be problematic and the `action_unfollow` method, called when the chat window is closed. The unfollow method deletes the agent member, but since the guest cookie is still present, the `channels_as_member` rpc retrieves the guest member. The rest of the code doesn't expect this mismatch and a crash occurs. This commit ensures the `channels_as_member` rpc is properly done before closing the chat window. runbot-237947 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#244677
This update combines member and live chat information automatically when creating helpdesk tickets, providing a more complete view of the customer's interaction. Previously, this data was displayed separately, which was confusing for support staff. This change streamlines the support process and improves customer service.
Original PR description
*: website_helpdesk_livechat, whatsapp Task-5496830 https://github.com/odoo/odoo/pull/243864 Forward-Port-Of: odoo/enterprise#104644 Forward-Port-Of: odoo/enterprise#104435
This update fixes an issue where payslip names were not being generated accurately in the Chinese HR payroll module. The change ensures that payslip names are now correctly computed, improving data accuracy and reporting for payroll processing. This impacts the accuracy of payroll reports and employee records.
Original PR description
Forward-Port-Of: odoo/enterprise#104376 Forward-Port-Of: odoo/enterprise#104289
This update fixes a potential issue where default journal types for Turkish invoice documents were incorrectly set. The default value has been changed from 'in_invoice' to 'purchase' to prevent incorrect accounting and ensure proper document handling. This ensures compliance and avoids potential errors in financial reporting.
Original PR description
…hing The default value of the journal type parameter was incorrectly set to a move type (`in_invoice`). Although all current callers explicitly pass the correct journal type, the default value has been corrected to `purchase` to avoid potential misuse. no task-id Forward-Port-Of: odoo/odoo#243139 Forward-Port-Of: odoo/odoo#242865
13 changes
Resolved issues and error corrections
This update fixes an issue where clicking links within the Odoo chat window on mobile devices caused the chat window to remain open and cover the new page. Now, the chat window automatically folds when a link is clicked, ensuring users can easily view the linked page without manually adjusting the chat window.
Original PR description
Clicking on an odoo link in the chat window will take the user to the related page in odoo. However, in mobile view, the chat window remains unfolded and covers the entire page, so the user can't see the newly opened page below the chat window unless they fold the chat window. This change fixes this by folding the chat window in mobile view when clicking an odoo link inside the chat window. task-4762503 Forward-Port-Of: odoo/odoo#244383 Forward-Port-Of: odoo/odoo#208440
This update resolves an issue where changing a tax lock date to a past date would trigger an error. The fix prevents the system from generating default external values when the lock date is set in the past, ensuring smoother operation and preventing unexpected errors related to date calculations.
Original PR description
To reproduce the issue, on a company in Luxembourg: 1) Set a tax lock date to November 30th 2) Attempt to change the tax lock date to November 15th ===> Lock date violation error. This happens because _generate_default_external_values still gets called in case the lock date is set back in the past (since _get_current_period_dates call in _create_default_report_external_values returns a tuple basically containing (former lock date + 1 day, new lock date)). Doing so, it tries generating a default external value with a value of 0 (because no data will ever be available in such an impossible date interval), but the previously set lock date prevents it, and raises the error. opw-5383010 Forward-Port-Of: odoo/enterprise#102756
This update enhances the security of user profile editing by utilizing a new internal helper function, '_can_edit_country()', to determine if a user is authorized to change their country setting. This change, implemented as a fix, ensures that profile editing aligns with security standards introduced in Odoo 18.4.
Original PR description
In 'save_edited_profile()', we check that the user can edit his country_id if he tries. As from saas-18.4, a new helper '_can_edit_country()' is available. This commit uses that helper to perform the check. Follow-up of #239789 Task-5331916 Forward-Port-Of: odoo/odoo#244694
This update fixes a potential issue where negative taxable income amounts appeared on payslips when state deductions exceeded employee gross income. The change ensures that taxable income defaults to zero in these scenarios, preventing incorrect financial reporting and improving payroll accuracy. This resolves a prior bug related to state tax calculations.
Original PR description
This commit simply defaults the computed taxable income amount to 0 in case the state deductions are greater than their gross income. Otherwise our payslips would imply that these employees are owed money by the state opw-5137280 Forward-Port-Of: odoo/enterprise#102599 Forward-Port-Of: odoo/enterprise#98114
This update fixes a technical issue where a new fiscal reform field was incorrectly used in the point-of-sale module. The change ensures the module aligns with legal requirements and automatically installed features. This correction was prompted by a customer and maintains consistent behavior with other fiscal reform modules.
Original PR description
`l10n_br_operation_type_pos_id` is a new field introduced in the fiscal reform [1] in saas-18.4. It's added in `l10n_br_edi_pos_fiscal_reform`, but is mistakenly used in `l10n_br_edi_pos`. Because the modules are legally required since the beginning of January and auto-installed it wasn't notice until now. This reverts the change to `l10n_br_edi_pos` and moves the logic to an override in `l10n_br_edi_pos_fiscal_reform`. Additionally, we only do it if the fiscal reform is enabled on the database with `l10n_br_is_icbs`, like we do for all other fiscal reform features. Thanks to ANDG for pointing it out. [1] odoo/enterprise#102835 Forward-Port-Of: odoo/enterprise#104671
This update removes unnecessary integer rounding from the monthly Italian VAT reports. The rounding was mistakenly carried over from annual reports, a consequence of a previous split in the reporting functionality. This ensures accurate VAT calculations for monthly reporting.
Original PR description
Integer rounding is only required on annual l10n_it VAT reports. It appears that it was incorrectly added to the monthly report when the two were split in [#193662](https://github.com/odoo/odoo/pull/193662). [opw-5292310](https://www.odoo.com/odoo/project.task/project.task/5292310) Forward-Port-Of: odoo/enterprise#104228 Forward-Port-Of: odoo/enterprise#103852
This update corrects a technical issue where performing an undo operation within the HTML editor would generate a traceback error. The fix ensures that undoing actions now functions smoothly without causing errors, improving the overall stability and usability of the editor. This resolves a minor bug that could potentially disrupt user workflows.
Original PR description
Current behavior before PR: - Inserting a /code block, then adding text above it and performing an undo would trigger a traceback. Desired behavior after PR is merged: - Undo now correctly removes the inserted character without causing any traceback. task-5445873
This update corrects an issue where product references were appearing in the names of products displayed on the website's product carousel. This change ensures that product names are clean and accurate, improving the user experience for customers browsing our online store. The fix was triggered by a specific scenario involving a product with a single value in its free text attribute.
Original PR description
**Issue**
When a product has a free text attribute with one value, the product reference appears in the name of the product on the product carousel.
**Expected behavior**
The product reference should not appear in the name of the product on the product carousel.
**Steps to reproduce**
1. Create a product to be sold online
2. Give it an internal reference
3. Add a free text attribute with one value
4. Set a product carousel on a website page
5. Disable "show variants" in the settings of the carousel
=> The product reference appears in the name of the product
**Note**
The issue happened only if the free text attribute has only one value, with more than one value, the product reference did not appear.
**Fix**
Updated the QWeb template to use the prepared clean title with data.get('display_name') instead of record.display_name
opw-5410822
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#242791A recent update to the delivery system caused an issue that was subsequently identified. This pull request reverts the problematic changes to restore the previous, correct behavior. The issue will be addressed in a future update.
Original PR description
Bug introdcued in: https://github.com/odoo/odoo/commit/6901863d30f524c160971c9f5c97846ffd1fa5f5 The fix was misleading because forcing the context in the unit test caused incorrect assumptions. Passing `default_carrier_id` in the context prevents the computed method from being called, breaking expected behavior. This revert restores the previous behavior as the fix is incorrect. The issue will be resolved in another PR. Forward-Port-Of: odoo/odoo#244774
This update resolves an issue that previously caused errors when adding new transcription snippets to records before they were saved. The change ensures that record IDs are correctly established, preventing these errors and improving the stability of the AI transcription component. This enhances the user experience by allowing users to consistently add and manage transcription snippets.
Original PR description
This PR fixes an issues where an exception would be thrown when inserting a transcription snippet on an unsaved record. It does so by removing the resId, resModel props and only retrieving them when actually needed (when opening the full composer to send the summary). Also whennever opening the full composer, we force a save on the record to ensure proper resId. task-5788331
This update corrects a minor issue in how overtime hours are recorded, ensuring more accurate calculations for employee balances and reporting. Previously, overtime was rounded to two decimal places, leading to potential inaccuracies when aggregating data. This change improves the reliability of overtime calculations, particularly for large teams and reporting needs.
Original PR description
### Current behavior: Overtime hours are stored with a two-decimal precision. This means a minute is stored as a minute and twelve seconds in the worst case, which would amplify The overtime given or taken on a particular attendance. This is problematic when aggregating the records for large datasets to compute the balance or for reporting ### Expected behavior: A minute should be stored closer to its real decimal value to minimize the error in aggregations. as a minute and 1.2 seconds opw-5422827 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a potential issue in the Nilvera accounting module where the default journal type was incorrectly set. The default has been changed from 'in_invoice' to 'purchase' to prevent incorrect document generation. This ensures Nilvera documents are created with the appropriate accounting settings.
Original PR description
…hing The default value of the journal type parameter was incorrectly set to a move type (`in_invoice`). Although all current callers explicitly pass the correct journal type, the default value has been corrected to `purchase` to avoid potential misuse. no task-id Forward-Port-Of: odoo/odoo#242865
This update prevents the API documentation endpoint from crashing when encountering models not currently defined in Odoo's code. The fix addresses a situation where outdated model definitions in the database would cause a server error. This ensures the documentation is consistently available.
Original PR description
When accessing the API documentation endpoint (`/doc`), the server could crash with an Internal Server Error if the database contained ir.model records for models that are not loaded in the current registry. Steps to reproduce: 1. Insert a record into `ir_model` with `model='ghost.model'` and `state='base'`. 2. Open `/doc`. 3. The server raises a `KeyError: 'ghost.model'`. Root Cause: The `/doc` endpoint iterates over all records in `ir.model`. For each record, it attempts to resolve the Python class using `self.env[ir_model.model]` to check access rights. If a model exists in the database with `state='base'`, Odoo expects it to be defined in the Python source code and does not generate it dynamically. If the corresponding Python class is missing (e.g., from an old module), it is never added to the registry, causing the lookup to fail with a `KeyError`. opw-5401782
9 changes
Resolved issues and error corrections
This update resolves an issue where invoices sent to Viettel's SInvoice system were failing due to incorrect tax amount formatting. The change ensures the tax amount is calculated using the currency's rounding method, aligning with SInvoice's requirements and preventing errors.
Original PR description
When sending an invoice to SInvoice (Viettel), the API raises an `INVALID_DECIMAL_POINT_TAX_MONEY` error if the tax amount contains excessive decimal places (e.g., 100.02999999999997). This occurs because the tax amount is currently calculated using simple subtraction (`total - subtotal`). Due to standard floating-point precision issues, this can result in unrounded values that the API rejects. The tax amount calculation is now updated to explicitly use the currency's rounding method, ensuring the value is accepted by SInvoice. task-[5484845](https://www.odoo.com/odoo/project/967/tasks/5484845)
This update corrects errors in VAT import billing by adjusting the default accounts used when creating invoices. Specifically, the account number 33312 was updated, resolving incorrect journal entries. This ensures accurate financial reporting for VAT transactions.
Original PR description
Due to the change of account 33312 from liability to payable, the journal entries generated when creating bills with VAT import taxes were incorrect. This fix updates the default account on the following taxes: - tax_purchase_import_10 - tax_purchase_import_8 - tax_purchase_import_5 task-5695253
This update fixes an issue where Odoo was creating duplicate vendor contacts when receiving invoices with slightly different VAT number formats (with or without dots). Now, Odoo will correctly identify and link invoices with the same VAT number, regardless of formatting variations, ensuring accurate record-keeping.
Original PR description
Description of the issue/feature this PR addresses: Odoo can create two contacts for the same VAT number Current behavior before PR: If you have two incoming vendor bills (over a period of time)…
Description of the issue/feature this PR addresses: Odoo can create two contacts for the same VAT number Current behavior before PR: If you have two incoming vendor bills (over a period of time) where the first bill has these details: - VAT number: `BE0477472701` - Name: `Odoo` And the second bill (e.g three months later) has these details: - VAT number: `BE0477.472.701` - Name: `Odoo S.A` Odoo will do something interesting and will create a second new contact. The reason is because the fallback on `name` from `res.partner` fails (since "Odoo S.A" is not equal to "Odoo". However, the `vat` number matching also fails! Since the VAT number "BE0477.472.701" is not identical to "BE0477472701". Throughout Odoo however VAT numbers are parsed and stored without dots in it. The function `_retrieve_partner_with_vat` however is an exception because the `vat` number here is sanitized for spaces but not for dots. Because of the combination of no exact match on neither `name` nor `vat` it now creates a second contact although the VAT number is technically the same. Desired behavior after PR is merged: Both an incoming vendor bill with `0477.472.701` and `0477472701` match to the same contact even if there are dots in it and if the name of the company is different. P.S: please find two sample XML's here: [sample_odoo_sa_bill.xml](https://github.com/user-attachments/files/24718225/sample_odoo_sa_bill.xml) [sample_odoo_bill.xml](https://github.com/user-attachments/files/24718226/sample_odoo_bill.xml) If you upload both back to back on a default V19 you will see two contacts. After this code change you will only see one contact where both bills are mapped to the same contacts. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244572
This update corrects a typographical error in the tests for the search highlight feature within Odoo. This ensures the search functionality operates correctly and reliably, preventing potential issues with how search results are displayed to users. The fix improves the overall stability and accuracy of the search experience.
Original PR description
Intoduced by https://github.com/odoo/odoo/pull/118794 Forward-Port-Of: odoo/odoo#244720
This update resolves an issue where deleting a recurring calendar event caused the application to reset filters and lose context-specific settings, disrupting subsequent record creation. The fix prevents a full page reload, ensuring filters and relevant fields are preserved after event deletion.
Original PR description
Deleting a recurring calendar event triggers a full page reload, which resets the view to default, clearing active filters and causing context-dependent fields (like "Resources") to disappear during subsequent record creation. ### Steps to reproduce 1. Filter the Calendar view (e.g., "Everybody"). 2. Delete a recurring event. 3. Observe the page reload and filter reset. 4. Try to create a new record; context-specific fields are missing. The issue occurs because the deletion action forces a browser refresh (location.reload()), wiping the web client's in-memory state. This state holds the active filters and context keys necessary for rendering specific fields. When cleared, the application reverts to its default configuration. opw-5433604
This update fixes a potential crash in the Italian EDI invoicing process when invoices are created with zero amounts in a foreign currency (like USD). The fix prevents a division-by-zero error during currency conversion, ensuring invoices can be generated correctly. This improves stability and avoids disruptions for users.
Original PR description
**Steps to reproduce:** 1. Install the `l10n_it_edi` and switch to IT company 2. Go to Accounting → Invoice. 3. Create an invoice add partner and change the currency to USD 4. Add a product and apply tax and discount of 100% and confirm 3. Click on Send **Issue:** A ZeroDivisionError is raised during the Italian EDI XML generation. `ZeroDivisionError: float division by zero` **Cause:** The conversion rate is computed by dividing `amount_total` by `amount_total_signed` without handling the case where `amount_total_signed` is `0.0`. **Solution:** Skip the conversion rate computation when the signed total amount is zero, preventing the division by zero **opw-5481821**
This update prevents the use of Amazon Payment Services in Odoo's self-order point-of-sale system. The issue stemmed from Amazon's requirement for customer identification, which isn't reliably available in self-order scenarios. This change ensures compatibility and prevents errors during payment processing.
Original PR description
Currently, it's impossible to use Amazon Payment Services as a online payment provider in the self order. We face a "Signature mismatch" error. Steps to reproduce: ------------------- * Set up the…
Currently, it's impossible to use Amazon Payment Services as a online payment provider in the self order. We face a "Signature mismatch" error. Steps to reproduce: ------------------- * Set up the payment porvider Amazon Payment Services * Create an online pos payment method using Amazon as provider * Set this payment method as the online method for a self * Place an order in the self * Try to pay it > Observation: When the page is redirected to provider's checkout page an error occurs, "Signature mismatch" Why the fix: ------------ Amazon Payment Services (APS) requires a customer to be identified in order to send its email into the request's signature. It is working fine on the website since during the checkout it will ask for the customer information and create a partner related. In the point of sale we cannot guarentee to have a customer registered on the order. Even worse for the self and kiosk, no customer will be registered. Since this provider is not compatible we do not allow it to be used with pos online payment methods. opw-5053492
A recent test was failing intermittently due to an issue with the way redirect URLs were being handled. This update corrects the test to account for both absolute and relative URLs, ensuring consistent test results. This resolves a technical problem that could have impacted the stability of the Odoo Enterprise system.
Original PR description
Bug === On some runs, the redirect URL is absolute and not relative, (eg: `http://127.0.0.1:8069/web/signup?db=...`) and so the test needs to be adapted. Task-5857520
This update resolves an error that occurred when generating PDF reports for accounting, specifically when a contact didn't have a name assigned. The fix ensures that the report exports correctly regardless of whether a contact has a name or not, improving the reliability of the reporting process.
Original PR description
Currently, an error occurs when exporting an accounting report to PDF if any of the selected contacts do not have a name. **Steps to reproduce:** - Install the `account_reports` and `contacts`…
Currently, an error occurs when exporting an accounting report to PDF if any of the selected contacts do not have a name. **Steps to reproduce:** - Install the `account_reports` and `contacts` modules. - Go to Contacts and open any contact (e.g., Azure Interior). - Click `Add` > `Save & Close`, then `save` the contact. - Navigate to Accounting > Reporting > Aged Receivable. - Click `Partners` button and select the newly created contact (e.g., `Azure Interior, Other Address`). - Click `PDF` to export the report. **Error:** `TypeError: sequence item 0: expected str instance, bool found` **Root Cause:** At [1], `options['selected_partner_ids']` is built using `partner.name`, which may be `False` for unnamed contacts. At [2], the `partner_value` list may therefore contain `False` entries coming from `options['selected_partner_ids']`. When calling `', '.join(partner_value)`, an error is raised because the list contains `non-string` (`bool`) values. **Fix:** This commit prevents errors when exporting reports to PDF and ensures that partner names are displayed in the report the same way as in the partner selection widget. [1]: https://github.com/odoo/enterprise/blob/a0ec2fcdc043cf52f1a646e84b9b97466072d47f/account_reports/models/account_report.py#L745 [2]: https://github.com/odoo/enterprise/blob/099c7b94ad08f83873c05ec528e16fbf806f47f2/account_reports/data/pdf_export_templates.xml#L84-L93 opw-5467321 Forward-Port-Of: odoo/enterprise#103828
1 change
Resolved issues and error corrections
This update resolves an error that occurred when generating PDF accounting reports if a contact lacked a name. The fix ensures that the report exports correctly even when a contact doesn't have a defined name, improving report generation reliability.
Original PR description
Currently, an error occurs when exporting an accounting report to PDF if any of the selected contacts do not have a name. **Steps to reproduce:** - Install the `account_reports` and `contacts`…
Currently, an error occurs when exporting an accounting report to PDF if any of the selected contacts do not have a name. **Steps to reproduce:** - Install the `account_reports` and `contacts` modules. - Go to Contacts and open any contact (e.g., Azure Interior). - Click `Add` > `Save & Close`, then `save` the contact. - Navigate to Accounting > Reporting > Aged Receivable. - Click `Partners` button and select the newly created contact (e.g., `Azure Interior, Other Address`). - Click `PDF` to export the report. **Error:** `TypeError: sequence item 0: expected str instance, bool found` **Root Cause:** At [1], `options['selected_partner_ids']` is built using `partner.name`, which may be `False` for unnamed contacts. At [2], the `partner_value` list may therefore contain `False` entries coming from `options['selected_partner_ids']`. When calling `', '.join(partner_value)`, an error is raised because the list contains `non-string` (`bool`) values. **Fix:** This commit prevents errors when exporting reports to PDF and ensures that partner names are displayed in the report the same way as in the partner selection widget. [1]: https://github.com/odoo/enterprise/blob/a0ec2fcdc043cf52f1a646e84b9b97466072d47f/account_reports/models/account_report.py#L745 [2]: https://github.com/odoo/enterprise/blob/099c7b94ad08f83873c05ec528e16fbf806f47f2/account_reports/data/pdf_export_templates.xml#L84-L93 opw-5467321