Tuesday, May 5, 2026
41 changes · saas-19.2
Enhancements to existing features
This update automatically sets the first available printer as the default for Point of Sale transactions. Previously, users had to manually select a printer, and this change simplifies the process. Additionally, restrictions have been added to prevent incorrect printer configurations, ensuring data integrity within the POS system.
Original PR description
Following this commit: ===== - Set first printer as default printer from the list configured. - Updated the help tooltip. - Added placeholder "None" to field product_categories_ids. - Restrict quick create for `receipt_printer_ids` and `default_receipt_printer_id` for pos.config and res.config.settings views task-5494313 Forward-Port-Of: odoo/odoo#246448
Resolved issues and error corrections
A bug was fixed that prevented the custom color settings for self-ordering kiosks from being applied. The issue stemmed from a missing data field, which defaulted to the standard color. This update ensures that self-ordering kiosks now correctly display the configured color scheme.
Original PR description
The background color configured for the self ordering / kiosk was not applied. This was caused because the `self_ordering_primary_color` field was not sent to the self order when loading the data, resulting in the default color always being used. --- Task: https://www.odoo.com/odoo/project/1737/tasks/6149865
This update resolves an issue where long image filenames in Odoo could cause website errors. The system now automatically shortens these filenames to prevent exceeding server limits, ensuring images load correctly and maintaining a stable user experience. This improves the reliability of image uploads and related features.
Original PR description
## Problem: When generating a filename for a related studio image field, if the `name` is excessively long, the response header may exceed nginx's buffer size of 4kb, causing the request to fail. ## Solution: We will truncate the assigned filename for binary streams to the first 255 characters of whatever the assigned name would have been. ## Steps to reproduce (Runbot 18): 1. Open Studio editor on a Sales Order 2. Edit List View on Sale Order Lines 3. + Related Field, Product > Image, image widget 4. Make the description very long (close to 4000 characters) 5. Note the image will not load for that SOL, and the network tab shows a 502 error opw-5360952 Forward-Port-Of: odoo/odoo#258498
A small typo in the quality module caused new quality alert records to be incorrectly grouped as 'None'. This update corrects the typo, ensuring records are properly assigned to the correct stages when created. This resolves a potential issue with data accuracy and reporting.
Original PR description
Issue: ------- While adapting the 'Domain' in the PR https://github.com/odoo/enterprise/commit/07b34a2e927347ca5c839ec632808adb02703e1f there occurred a typo where '|' got replaced with the '&' and causing the records getting grouped in 'None' when creating. Solution: ------------ To replace '&' with '|' to get the records grouped under the correct stage. Steps to reproduce: ----------------------- 1. In v19.0, in quality module try to create a quality alert record. 2. Just like that the newly created record will be under 'None'. Reference Image: <img width="1105" height="407" alt="image" src="https://github.com/user-attachments/assets/4c9c33be-ec06-4f06-8245-54dbe4473bc0" /> OPW - [6074016](https://www.odoo.com/odoo/project/70/tasks/6074016) Forward-Port-Of: odoo/enterprise#113108
This update resolves a crash in the form builder when using the 'Add other' option with radio buttons. The fix prevents a JavaScript error that occurred when the system tried to access data from a special input field created by the 'Add other' feature. Now, the form builder works reliably with this functionality.
Original PR description
When configuring a "Visible only if" condition that depends on a radio/checkbox field with the "Add other" option enabled, the form options panel crashed with: TypeError: Cannot read properties of…
When configuring a "Visible only if" condition that depends on a radio/checkbox field with the "Add other" option enabled, the form options panel crashed with:
TypeError: Cannot read properties of null (reading 'textContent')
Steps to reproduce:
====================
1. Go to /contactus and edit the form
2. Add a Radio Buttons field and enable "Add other"
3. Add another field and set "Visible only if" to depend on the radio field
=> TypeError, form options panel broken
Cause:
=======
The "Add other" feature inserts an additional `.o_other_input` text input next to the radio inputs (the free-text input shown when "Other" is selected). When loading the available condition values, the code iterated over every `.s_website_form_input` in the dependency container and looked up `label[for="${el.id}"]`. The `.o_other_input` has no `id` and no associated label, so `querySelector(...)` returned `null` and accessing `.textContent` threw.
The crash also prevented editing any field's label on the form until the page was reloaded.
Solution:
==========
Excluding `.o_other_input` from the iteration is correct: the "Other" choice is already represented in the list by its dedicated radio (with its own label), so the free-text payload input must not be treated as a separate condition value.
An alternative would have been to narrow the selector to `.s_website_form_input.form-check-input` (the class carried by radio and checkbox inputs), which also excludes the `.o_other_input`. The chosen approach (`:not(.o_other_input)`) is more explicit about the intent: skip the "Add other" payload input, regardless of any class additions to the radio/checkbox inputs in the future.
=> Visibility dependency loads correctly, only the radio choices
("Other" included via its radio label) are listed
opw-6170367
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update fixes an issue where copying a user also duplicated their associated tasks, leading to shared task assignments. The change ensures that tasks are correctly isolated to the new user, preventing conflicts and simplifying task management. This improves data consistency and reduces potential errors.
Original PR description
Duplicating a user also duplicates all their task assignments because task_ids on res.users is missing copy=False. The new user ends up sharing the same tasks in project_task_user_rel, so removing a task from either user affects both. Forward-Port-Of: odoo/enterprise#114270 Forward-Port-Of: odoo/enterprise#114028
This update ensures that EC Sales Reports generated for the Swedish market (l10n_se) are exported to KVR in whole numbers, as required by Swedish tax regulations. Previously, the export included decimal places, which was incorrect. This fix corrects the rounding logic to meet reporting standards.
Original PR description
**PROBLEM** EC Sales Report in Sweden needs to be reported with integer values. **STEP TO REPRODUCE** 1. Install l10n_se 2. On the se company, create a invoice with lines with EU tax and confirm it. 3. Go to Accounting/Reporting/EC Sale List and export to KVR. 4. Notices the KVR uses numbers with decimals places. opw-6045289 Forward-Port-Of: odoo/enterprise#115980 Forward-Port-Of: odoo/enterprise#114292
This update prevents Odoo from crashing when viewing order details without a linked employee. Previously, enabling 'Log in with Employees' after processing an order would cause issues. Now, the 'Served By' field defaults to the user who created the order, ensuring a smoother experience.
Original PR description
**Before this commit** When trying to open an order's details, we would crash when that order does not have an employee associated with it. This can happen when the "Log in with Employees" setting is…
**Before this commit** When trying to open an order's details, we would crash when that order does not have an employee associated with it. This can happen when the "Log in with Employees" setting is enabled after at least one order has already been processed. **After this commit** If there isn't an `employee_id` associated with an order, don't try to overwrite the "Served By" field. By default, this should allow the name of the user who processed the order to be displayed. This can be seen in the original `getOrderFields()` method on the `OrderDetailsDialog` component. https://github.com/odoo/odoo/blob/e1c81c326e370b0a7b5bc8018b151e251ebce544/addons/point_of_sale/static/src/app/screens/ticket_screen/order_details_dialog/order_details_dialog.js#L81 This commit is mostly a backport of the slight refactor in 19.3, with the added benefit of still showing the names of the users who processed orders before `pos_hr` was installed on the database. https://github.com/odoo/odoo/blob/be57b42442db8c6be219d36f8c3e07e8baf45e31/addons/pos_hr/static/src/app/screens/order_details_dialog.js#L10-L15 opw-6169880
This update simplifies the process for Dutch companies to manage their digipoort certificates within the accounting settings. Previously, users had to navigate to a separate section to create a certificate before selecting it. Now, users can directly create and edit digipoort certificates within the primary accounting settings, improving usability.
Original PR description
Description of the issue this commit addresses: In the Accounting settings on a Dutch company, the setting for the selection of the digipoort certificate only lets you choose amongst existing certificates so if you haven't created one yet, you need to go to the dedicated certificates menu to create one and then come back to the digipoort certificate setting to set it. This is poor UX. --- Desired behavior after this commit is merged: This is improved by letting the user Create and Edit inside the digipoort certificate setting directly. --- task-6065566 Forward-Port-Of: odoo/enterprise#115755 Forward-Port-Of: odoo/enterprise#114307
This update ensures that 'Final Consumer' records created within the CO Edition are correctly identified as individuals, not companies. Previously, a calculation error resulted in these records being incorrectly classified. The fix includes a necessary adjustment to the data and updated tests to guarantee accurate record creation.
Original PR description
After changes on is_company field to be computed, Final Consumer was being created as a company. Although this is wrong, tests were not asserting correctly on how anonymous documents should be created. This commit fixes this by forcing the value to False and correcting the tests. task-6149751 Forward-Port-Of: odoo/enterprise#115560
This update resolves an error that prevented users from submitting surveys with background images. The issue stemmed from outdated code referencing a removed component. The fix ensures background images load correctly during the survey submission process, improving the user experience.
Original PR description
### Issue before this commit: When the submit event is triggered, the system attempts to preload the background image for the next screen using SurveyPreloadImageMixin. However, this mixin is no longer used, which results in the following error: SurveyPreloadImageMixin is undefined ### Steps to Reproduce: 1. Install the Survey module 2. Create a new survey 3. Add a section with a background image 4. Add at least one question 5. Click on Test 6. Start the survey and submit the first page ### Cause of the Issue: The code still references SurveyPreloadImageMixin._preloadBackground, even though SurveyPreloadImageMixin has been removed/refactored. This leads to an undefined reference during execution. Refactored-commit: https://github.com/odoo/odoo/commit/50c03d966241da263a63ec7948e293a0475e9ba9 ### With This Commit: To ensure it works correctly, preloadBackground() is imported and called inside nextScreen(). opw-6165822 Forward-Port-Of: odoo/odoo#262424
This update resolves visual issues and ensures accurate Saudi document formatting. Specifically, it dynamically updates VAT information and standardizes paper formats for Saudi companies, improving the clarity and reliability of printed reports.
Original PR description
This commit introduces several improvements and fixes to the Saudi document layouts and company configurations: - Removes the redundant VAT number from document layout header to resolve visual overlapping with other elements. - Extracts `l10n_sa_edi_additional_identification_scheme` and `l10n_sa_edi_additional_identification_number` from static company details and injects them dynamically into document layouts so they always remain up-to-date when printed. - Updates the configuration logic to ensure the default Saudi paper format is applied to all SA companies. task-6040091 Forward-Port-Of: odoo/odoo#255463
This update corrects a technical issue where the Dutch translations for the 'l10n_nl_returns' module were missing from the project's translation files. Adding these translations ensures accurate and complete functionality for Dutch-speaking users of the Enterprise software. This resolves a potential display issue and improves the user experience.
Original PR description
This [commit](a6a8d121bbf2044793df5211c5bdb18859a62152) introduced a new module in a stable version (19.0) without the required key in the `.weblate.json` file. This commit aims at fixing that to ensure translations are handled correctly. Forward-Port-Of: odoo/enterprise#115753
This update resolves an issue where invoices generated with the l10n_sa and l10n_sa_edi modules were displaying a duplicate tax number. The change ensures that company details now print the tax number only once, improving invoice accuracy and presentation. This was related to a previous change in the Odoo codebase.
Original PR description
Before this change: - the additional_company_details would print a second tax number to invoice printout in l10n_sa After this change: - company details will print tax number only once Forward-Port-Of: odoo/odoo#261272
This update resolves a visual glitch where the user status icon on the dashboard incorrectly displayed a grey question mark instead of the correct work location. The fix standardizes the data format used for user status, ensuring the icon accurately reflects the user's location. This improves the user experience and consistency.
Original PR description
Steps to reproduce: ------------------------------ 1. Install `hr_homeworking` module 2. Go to User > Calendar Tab 3. Set location for the days (e.g, 'Office' for M-F, 'Home' for Sat/Sun) 4. Go back…
Steps to reproduce:
------------------------------
1. Install `hr_homeworking` module
2. Go to User > Calendar Tab
3. Set location for the days (e.g, 'Office' for M-F, 'Home' for Sat/Sun)
4. Go back to the app dashboard and reload
Observation:
------------------------------
You'll see that the status icon (top right) flashes online and then remains as the grey circle with a question mark.
Issue:
------------------------------
The im_status field had an inconsistent format across different parts of the codebase:
* `res_users.py` was setting `im_status` as `presence_office_online` (3-part format)
* `res_partner.py` was setting `im_status` as `office_online` (2-part format) https://github.com/odoo/odoo/blob/5d88f089764b08ef8fd06dc4add7cb6f4815f307/addons/hr_homeworking/models/res_partner.py#L18
* `im_status_patch.xml` expected the 2-part format and checked `persona.im_status.split('_').length == 2`
https://github.com/odoo/odoo/blob/5d88f089764b08ef8fd06dc4add7cb6f4815f307/addons/hr_homeworking/static/src/im_status_patch.xml#L6
When users had a work location set, `res_users._compute_im_status()` produced the 3-part format (presence_office_online), which failed the XML template's length check. This caused the template to fall through to the default '' placeholder, displaying a grey question mark icon instead of the proper location icon.
Solution:
------------------------------
Standardized on the 2-part format (location_status) because:
* Minimal changes required - Only 2 files needed modification
* Aligns with existing code - `res_partner.py` and `im_status_patch.xml` already used this format
https://github.com/odoo/odoo/blob/5d88f089764b08ef8fd06dc4add7cb6f4815f307/addons/hr_homeworking/static/src/im_status_patch.xml#L6
* Backward compatible - The main `im_status` template logic was already designed for this format
`avatar_card_resource_popover.xml` had hardcoded checks for the 3-part format (presence_home_online, presence_office_away, etc.). After fixing `res_users.py to use the 2-part format, these hardcoded checks would never match, causing the avatar card popover to not display location icons
opw-6064997
Forward-Port-Of: odoo/odoo#261977
Forward-Port-Of: odoo/odoo#258829This update fixes a potential issue where errors during holiday creation wouldn't be properly handled. By wrapping the core holiday creation logic in a try/except block, the system now catches and resolves validation errors more reliably, ensuring smoother holiday setup. This improves the overall user experience and data integrity.
Original PR description
this commit, in this PR:https://github.com/odoo/odoo/pull/242299 the create method was refactored to wrap only the _create_all_new_leave call in a try/except block, ensuring that ValidationError is caught at the correct. Task-6179171 Forward-Port-Of: odoo/odoo#262175
This update simplifies the process for creating Unsplash attachments, reducing complexity and potential security risks. Previously, broad access rights were required; now, only the necessary permission to set the attachment URL is granted, improving efficiency and security.
Original PR description
Only grant `sudo` to set the attachment `url` rather than applying sudo on the whole `.create` dict The purpose of the previous `_can_bypass_rights_on_media_dialog` was to allow employees uploading unsplash images to be able to create an attachment with an `url` while being a `type='binary'`, for the images to be able to be served with the URL `/unsplash/...`. Just applying `sudo` at the right needed spot rather than on the whole `create` requires less code to achieve the same goal. Forward-Port-Of: odoo/odoo#262394 Forward-Port-Of: odoo/odoo#261056
This update resolves a rejection issue with Mexican tax filings (NOM36) when payslips only include non-taxable payments. The change ensures the XML data sent to the SAT accurately reflects the situation, aligning with tax regulations and preventing errors.
Original PR description
When a payslip contains only OtrosPagos (no perceptions), the SAT rejects with NOM36 because TotalPercepciones must not exist per the nomina12 XSD. This is a valid scenario under LISR articles 93 and 94, where certain payments (e.g., viáticos, becas, fondo de ahorro patronal) do not constitute taxable salary income. Apply the same 'or None' pattern already used for TotalDeducciones, so format_float(None) returns None and the attribute is omitted from the XML. Forward-Port-Of: odoo/enterprise#115923
This update resolves an issue where the 'delete' action was unexpectedly removed after installing the 'data_cleaning' module for attachments. The change ensures that the original attachment view order is maintained, preventing conflicts and restoring the expected delete functionality. This improves the usability of the attachment management feature.
Original PR description
Steps: - Enable debug mode - Go to Attachments view (list) - Select several items - Actions -> You have delete - Install `data_cleaning` - Do the same - Actions -> You don't have delete anymore Context: - `IrUiView` has 16 by default for `priority` field and order set as `priority,name,id`. - `IrAttachment` has a default view with no name, so `ir.attachment` is taken by default. - `data_cleaning` creates a view named `Storage Detail` with no priority specified (so 16 by default) on model `ir.attachment`. That makes the `ir.attachment` view from `data_cleaning` before the original one if we use the order "priority,name,id", as both of them have 16 in priority and `Storage Detail` is before `ir.attachment`. This commit restore the previous behaviour by preventing `data_cleaning` from overriding original `ir.attacmhent` view. opw-6149907 Forward-Port-Of: odoo/enterprise#115421
This update fixes an issue where closed Helpdesk tickets were sending out emails with the incorrect ticket ID instead of the reference number. Previously, the 'Ticket Closed' email template used the database ID, leading to inconsistent information for customers. This change ensures all email communications accurately reflect the ticket reference number.
Original PR description
Steps to reproduce: ------------------------ 1. Install the Helpdesk. 2. Go to Settings → Technical → Sequences and set the next number to 100. 3. Create a ticket and send a message using the…
Steps to reproduce: ------------------------ 1. Install the Helpdesk. 2. Go to Settings → Technical → Sequences and set the next number to 100. 3. Create a ticket and send a message using the "Helpdesk: Ticket Received" mail template; Observe that the correct reference (100) is used. (Open the full composer to use "Load template") 4. Now send a message using the "Helpdesk: Ticket Closed" mail template and Observe that it displays the database ID (e.g., 1) instead of the reference. Cause: ------ `new_ticket_request_email_template` uses the ticket reference(`object.ticket_ref`) correctly. https://github.com/odoo/enterprise/blob/d39e291ba89ad018ba6f5f9591d280a834822f27/helpdesk/data/mail_template_data.xml#L18-L19 However, the `solved_ticket_request_email_template` uses the database ID (`object.id`) instead of the actual ticket reference (`object.ticket_ref`), leading to inconsistent references in customer communications. related commit: 3ed5273 Solution: --------- Update `solved_ticket_request_email_template` to use `object.ticket_ref` instead of `object.id` opw-6087466 Forward-Port-Of: odoo/enterprise#115946 Forward-Port-Of: odoo/enterprise#113932
A bug in the Odoo spreadsheet functionality was causing the user interface to freeze when a specific function was used. This update fixes an infinite loop within the spreadsheet, preventing this freezing issue and ensuring a stable user experience. This resolves a reported performance problem.
Original PR description
When using `ODOO.LIST.HEADER(1, <empty_cell_ref>)`, the spreadsheet enters an infinite evaluation loop, causing the UI to freeze. Task: 6171185 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#262037 Forward-Port-Of: odoo/odoo#261724
This update corrects a technical error that prevented live chat channels with AI agents from appearing correctly to users. The fix ensures that all live chat channels, regardless of agent type, are accurately displayed. This improves the user experience and functionality of the live chat feature.
Original PR description
The number of agents linked to a livechat channel was always 0 because of a mistake in the code. This prevented livechat channels with AI agents from appearing to users. This commit fixes the problem. task-5409200 Forward-Port-Of: odoo/enterprise#111574
This update fixes an issue where users were encountering errors when authorizing multiple Shopee shops through a Shopee Account. Now, the system correctly reuses authorization tokens, streamlining the process and preventing duplicate requests. This ensures a smoother onboarding experience for users managing multiple shops.
Original PR description
When authorizing a Shopee shop, a user has the choice to either connect to a Shopee Shop, or connect to a Shopee Account and grant access to multiple shops of the account. In the later scenario, the authorization code returned by Shopee OAuth should be used once to fetch the access tokens, and the tokens should be copied to all shops authorized by the account. However, when the shop already existed, the access token was fetched again, raising an error because the authorization code had already been used. opw-6166585 Forward-Port-Of: odoo/enterprise#116000
This fix addresses an issue where the employee chat button was missing from the employee form after linking a user. The button has been restored to allow employees to quickly access the Discuss channel, improving communication and efficiency.
Original PR description
Steps to reproduce: ------------------- 1. Install Employees. 2. Create a new employee record. 3. Link a user to the employee. Current behavior: ----------------- The chat (Discuss) button is no longer visible on the employee form, even when a user is linked to the employee. related commit: 7603d92 Expected behavior: ------------------ The chat button should be displayed when an employee has a linked user, allowing quick access to Discuss. opw-6158991 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a visual alignment issue within the HR Payroll module, ensuring the review status widget is correctly positioned alongside the employee chat button. This improves the user experience and makes it easier for users to access important review information.
Original PR description
Move the review status widget inside the `employee_chat_button` wrapper, so it is displayed alongside the chat button instead of being misaligned. related community https://github.com/odoo/odoo/pull/261780 opw-6158991
This update corrects an issue where the 'GST Username' field remained visible even when GST reporting was disabled. The field has been moved back to the 'Registered Under GST' block, ensuring it only appears when GST functionality is enabled. This ensures a more consistent and logical user experience for GST reporting.
Original PR description
In https://github.com/odoo/enterprise/commit/427d9dfb89e1690d851054f7d0706648dc9bb512 commit we move the 'GST Username' field under the 'GST Reports & E-Filing' block. In this commit: - Move back the 'GST Username' field under the 'Registered Under GST' block. Reason: - Reverted this change because the visibility logic around GST fields was inconsistent. Even when “GST Reports & E-Filing” was unchecked, the “GST Username” field remained visible, which is not expected. - To restore a more logical behavior, we moved the “GST Username” field back under the “Registered Under GST” block, ensuring it only appears when GST is actually enabled. task-5248629
This update resolves an issue where channel mentions stopped functioning correctly. A technical error allowed code with failing tests to be merged, causing the disruption. This fix ensures channel mentions are working as expected, improving communication within Odoo.
Original PR description
Forward-port of PR introduced regression where channel mention was no longer working [1]. There was a bug on runbot that didn't prevent merging code with failed test. This commit fixes the typo. [1]: https://github.com/odoo/odoo/pull/260457 Forward-Port-Of: odoo/odoo#261083
This update corrects a recent change in how Odoo uses its GeoIP databases. Previously, the system incorrectly favored the larger city database as a fallback, which could have impacted location accuracy. This fix reverts the previous change, ensuring the system utilizes the appropriate database based on compatibility for optimal performance and location data.
Original PR description
There are two geoip database: a small and fast-to-query country database, and a big but slower-to-query city database. As the City record inherits from the Country record, we can access the country…
There are two geoip database: a small and fast-to-query country database, and a big but slower-to-query city database. As the City record inherits from the Country record, we can access the country informations from the City record. In our case it means that when the ip was geolocalized against the city db, we can reuse the city record for the country informations, we don't need to query the country db. It also means that in case the country database does not exist, we can query the city database for the equivalent country information: it is slower but returns the information. In commit 06b0e0017651 we tried to simplify the code a bit, and decided to return the city database as fallback to the country database when the latter was not found/corrupt. This is wrong because if the city and country *records* are indeed compatible, the city and country *databases* are not. This commit reverts the changes that were included in the `[MOV]` commit. Reference-to: 06b0e0017651 ([MOV] core: http.router.root.geoip -> http.geoip)
This update resolves an issue preventing users from changing chart templates for companies without journal entries when cash rounding is enabled. The fix ensures that chart template swaps no longer cause errors, providing greater flexibility in managing company financial settings. This improves usability and reduces potential disruptions.
Original PR description
Allow changing chart template for companies without journal entries even if cash rounding exists. Previously, profit_account_id in account.cash.rounding caused a traceback because this account is deleted during the chart's swap. task-5232399
This update resolves an issue where incorrect pivot IDs were used in purchase and vendor dashboards. The fix ensures accurate data representation within these reports, improving the reliability of key business insights related to purchasing and vendor management.
Original PR description
This commits fixes the pivot id in some formulas. Task: 5875749 Forward-Port-Of: odoo/enterprise#114559
This update fixes a bug where an unwanted image option was visible in the email marketing builder. The changes ensure that only relevant options are displayed, improving the user experience and preventing confusion. The update also streamlines the alert option to use the correct template and remove redundant size options.
Original PR description
Commit 1 -------------- From the [commit], the options API was refactored to not use `OptionComponent` when adding an option. The mass mailing builder used the `ImageToolOptionPlugin` which replaced…
Commit 1 -------------- From the [commit], the options API was refactored to not use `OptionComponent` when adding an option. The mass mailing builder used the `ImageToolOptionPlugin` which replaced the `OptionComponent` with some modified version. As the `OptionComponent` is no longer present in the base option, patching the same won't use the modified option. Hence, the option became visible in the mass mailing builder. This commit adapts the mass mailing builder with the refactoring of the options API to keep the image transform option hidden. Also, the size option for the image have been adapted to consider the original options condition. [commit]: https://github.com/odoo/odoo/commit/179480d996a19dff4d56265a610259b1c6e33f99 Commit 2 ------------------- ### Steps to reproduce 1. Open Email Marketing 2. Open/Create a Mailing 3. In the editor, insert an `Alert` block. --------> Some options won't be visible. ### Technical The [commit] restructured the `Alert` snippet, therefore, for the builder to identify the mass mailing's alert block, we need to adapt the selector of the option to `.s_mail_alert`. After this commit, the following options will become visible (which were invisible before the commit): - Background Color - Border Option Note: 1. mass_mailing's `Alert` option now correctly uses the mass mailing's option template. Which included different size options, but those are now already added by `size_option_plugin`. Therefore this commit also removes those redudant size options from the alert option. 2. The width option for the `Alert` block is already added by original `width_option_plugin`, therefore we remove the patch of the selector inside mass mailing to avoid redundancy. [commit]: https://github.com/odoo/odoo/commit/b6e51609807bdb771f305ba289aafe3e2b9b26b6 Task-5999942 Forward-Port-Of: odoo/odoo#262361 Forward-Port-Of: odoo/odoo#260923
This update resolves a problem where the 'unfold all' option was incorrectly applied during the export of aged receivable reports (like PDFs). Previously, this resulted in overly complex reports. This change ensures that reports are generated with the correct level of detail, improving usability and report clarity.
Original PR description
This commit introduced a small issue: https://github.com/odoo/enterprise/commit/40484f985f511edd7ba2ae759ce63ef564bcf1f7 When exporting a report (the aged receivable in pdf for example), the option key "unfold_all" was set but shouldn't be.
This update resolves an issue where users lacking specific permissions on employee records would encounter an access error when attempting to view attendance data. The change corrects a technical error related to accessing employee data fields, ensuring a smoother experience for all users. This fix improves usability and prevents disruptions to attendance reporting.
Original PR description
Steps to reproduce: ---------------------------------------- - Connect with a user having no rights on Employee - Try to open Attendances - Access error Cause: ---------------------------------------- Since 218b91cad3e50b27a84624145c89ed6bb23f18c5 we read the field `is_flexible` on employee which is a field only accessible to `hr.group_hr_user` ([src](https://github.com/odoo/odoo/blob/70ade77937bfc171a3352e70c5c78bfd87ceb4d1/addons/hr/models/hr_version.py#L154)). opw-6179252
This update resolves an issue where manufacturing order confirmations incorrectly triggered consumption alerts for certain components. The fix ensures that component compatibility with the specific product variant is now checked, preventing unnecessary alerts and streamlining the production process. This improves accuracy and reduces potential delays.
Original PR description
Steps to reproduce the bug:
- Create a storable product “P1”:
- Variant: Color -> Red & Blue
- BoM: -Components: - C1: apply on variant Blue - C2: apply on all variant
- Create a manufacturing order to produce one P1 red
- only the move raw C2 is created -> expected behavior
- Confirm the MO
- Try to validate the production
Problem:
A consumption issues is triggered to indicate that C1 is missing
Explication:
When confirming a manufacturing order, we checks if some BoM components are missing and may trigger a consumption issue.
However, the check was done on all BoM lines of the exploded BoM, without verifying whether the component was compatible with the variant being produced.
As a result, a consumption issue could be raised even when the missing component was not supposed to be consumed for the selected variant.
opw-6062762A small bug fix has been implemented to ensure that operation durations displayed in the Gantt view are accurately shown in hours instead of minutes. This ensures that users see the correct time estimates for work orders, improving planning accuracy. The change was triggered by a previous formatting update.
Original PR description
Issue ----- In the gantt view, operation duration is displayed as minutes but is actually in hours. Steps to reproduce ----- - Enable work orders - Create a product with a BoM - Add an operation with some duration on the BoM - Creation a MO for the product, confirm & plan - Open the gantt view > Duration is displayed in minutes Cause ----- Overlooked by the rework of formatter done in b764335. Value is in hours but unit is set to "minutes". https://github.com/odoo/enterprise/blob/8281fe6c830dce94ca851bf4bd5c768443721f17/mrp_workorder/static/src/mrp_workorder_gantt_renderer.js#L46-L49 ----- Ticket: opw-6109524
A technical error prevented importing emissions data through the ESG reporting module. This update restricts imports to manual emissions data, resolving a database conflict issue related to journal entry emissions. This ensures data integrity and stability within the ESG reporting functionality.
Original PR description
The import button is present in the Emitted Emissions menu, but it produces the following error: "cannot insert into view 'esg_carbon_emission_report' DETAIL: Views containing UNION, INTERSECT, or EXCEPT are not automatically updatable." => To fix this, we will only allow the insertion of manual emissions (model: other.emission) via import, not emissions related to journal entries. task-6168587 Forward-Port-Of: odoo/enterprise#115856 Forward-Port-Of: odoo/enterprise#115306
This update corrects a bug that prevented users from saving settings when GST registration was unregistered. The fix ensures the system correctly validates required fields based on the user's GST registration status, preventing a 'Missing Required Fields' error.
Original PR description
**Steps to reproduce:** * Install `l10n_in` module. * Go to Accounting > Settings. * Check 'Fetch Vendor E-Invoiced Document` and clear the GST Username * Uncheck `Registered Under GST`. * Try to…
**Steps to reproduce:** * Install `l10n_in` module. * Go to Accounting > Settings. * Check 'Fetch Vendor E-Invoiced Document` and clear the GST Username * Uncheck `Registered Under GST`. * Try to modify any setting and save. **Observed behavior:** * A `Missing Required Fields` error is raised even though no visible field is missing a value. **Cause:** * The `l10n_in_gstr_gst_username` field is placed inside a `div` that is hidden when `l10n_in_is_gst_registered` is `False`. * However, its `required` condition only checked `l10n_in_gst_efiling_feature or l10n_in_fetch_vendor_edi_feature`, without accounting for `l10n_in_is_gst_registered`. * Since both features default to enabled, the field remained required even when invisible, blocking any settings save. **Fix:** * Update the `required` attribute on `l10n_in_gstr_gst_username` to include `l10n_in_is_gst_registered` as a condition, so the field is only required when the GST section is visible and either `GST E-Filing & Matching` or `Fetch Vendor E-Invoiced Document` is enabled. opw-6133001 Forward-Port-Of: odoo/enterprise#114423
This update resolves an issue where tours for the purchase and stock modules didn't initiate correctly in community builds. The fix leverages an existing utility function to ensure tours open properly, regardless of whether the enterprise version is installed. This ensures a consistent and functional experience for all users.
Original PR description
The tours: - `test_basic_purchase_flow_with_minimal_access_rights` - `test_basic_stock_flow_with_minimal_access_rights` fail to perform the first step if enterprise is not in the addons path since the app icons are not in the the main view. Fortunately, a general util is already present to perform the task of opening the app in both community and enterprise builds: https://github.com/odoo/odoo/blob/e258de4235b4872e0427017e22b46495080c25dc/addons/web_tour/static/src/tour_utils.js#L81-L101 https://github.com/odoo/odoo/blob/e258de4235b4872e0427017e22b46495080c25dc/addons/web_tour/static/src/tour_utils.js#L36-L43 runbot-240934 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262559
This update fixes a bug that prevented users from assigning recruiters to new job positions when the hr_payroll module wasn't installed. The fix ensures the necessary data is consistently available, resolving an error message and improving the user experience. This change enhances the reliability of the recruitment process.
Original PR description
**Steps to Reproduce:** 1. Ensure hr_payroll module is NOT installed 2. Open a Job Position in hr_recruitment app 3. Click on "Assign Recruiter" button for a position without a recruiter 4. Observe error: "Name 'company_id' is not defined" **Bug Cause:** The interviewer_ids field on hr.job uses a string domain that references company_id. Since company_id is not available in the current view without hr_payroll it fails. **Solution:** Add `<field name="company_id"/>` to the hr_job_kanban view to ensure the field is consistently available for domain evaluation regardless of other installed modules. **Task:** 6106143 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259305
This update ensures continued functionality with Sendcloud by adding a compatibility key. Sendcloud has transitioned to a new API version, and this change allows Odoo to continue using the older, supported version for existing customers. Future work will focus on upgrading to the latest Sendcloud API.
Original PR description
Sendcloud pass their api v2 to maintenance and only provide new api V3 key to the new customers. In order to make a smooth transition for the user we add the partner key, so they know that the customer are coming from odoo and they use the v2 api. Future work will be done to upgrade our module and support the v3. API key. Forward-Port-Of: odoo/enterprise#114544 Forward-Port-Of: odoo/enterprise#114441
This update fixes a minor calculation error in the 'l10n_ar_withholding' module related to payment processing. The system was incorrectly calculating withholding taxes, resulting in a slight discrepancy in the total payment amount. This fix ensures accurate withholding calculations for payments, guaranteeing correct tax reporting.
Original PR description
**Steps to reproduce:** * Install `l10n_ar_withholding` module. * Create a vendor bill and click on 'Register Payment' to open the payment wizard. (i.e. amount 25000, tax 21%) * Select 'Own Checks'…
**Steps to reproduce:** * Install `l10n_ar_withholding` module. * Create a vendor bill and click on 'Register Payment' to open the payment wizard. (i.e. amount 25000, tax 21%) * Select 'Own Checks' within the payment method. * Clear Withholding lines and add line with tax `IIBB WTH CABA`. * In the Checks tab, input the check number, date, and amount (30000) natively. * The computation of the withholding lines is triggered. **Observed behavior:** * The total gross amount registered computes to exactly $30,247.93 instead of mathematically converging to the true original invoice debt of $30,250.00. **Cause:** * The `l10n_ar_withholding` module uses an iterative mathematical solver to progressively bump `wizard.amount` upward to effortlessly offset and scale the equivalent proportionate withholding taxes accurately. * However, inside Odoo's iterative memory loop (`for i in range(201)`), the ORM caches computed values across passes for NewId performance. As `wizard.amount` increments upwards, the dynamically dependent `l10n_ar_withholding_ids.base_amount` and `amount` fields fail to automatically invalidate their internal cache. * The loop relies on these statically cached values (e.g., $247.93) to verify if equilibrium has been reached, wrongfully satisfying the balancing exit condition and halting the loop prematurely. **Fix:** * Recompute the `base_amount`, `amount` using `add_to_compute` on the `l10n_ar_withholding_ids` automatically inside the iterative loop in `account_payment_register.py`. * This signals the ORM to cleanly dump the stale cache dependencies, natively forcing mathematically correct recalculations of the proportionate untaxed withholdings at every incremental `wizard.amount` step. The solver now strictly converges optimally to exactly block the correct value in 1-2 rapid passes without hanging on legacy computation artifacts. opw-5934489 Forward-Port-Of: odoo/odoo#254635