Friday, June 12, 2026
41 changes · saas-19.3
Enhancements to existing features
This update ensures Odoo complies with Serbian accounting regulations by automatically fetching the official mid-market exchange rate from the National Bank of Serbia. This improves the accuracy of financial reporting for Serbian businesses using Odoo Enterprise. It’s a necessary step for legal compliance.
Original PR description
[IMP] currency_rate_live: Fetch exchange rates National Bank Serbia To ensure compliance with the Serbian Law on accounting, fetch official middle exchange rate from the National Bank of Serbia task-6159555 Forward-Port-Of: odoo/enterprise#116935
Resolved issues and error corrections
This update streamlines the process of loading contract templates by simplifying a key component. Previously, the button's database calls were inefficient due to its reliance on a broader selection field. This change improves performance and stability.
Original PR description
It was found that the Load Contract Template button was doing database calls with no domain. This was due to it extending Selection Field, seeing that it doesn't use anything from SelectionField except the props, we've decided to make it a simple Component. task-6259618 Forward-Port-Of: odoo/odoo#268825
This update fixes a bug where timesheet totals weren't visible on the portal's task view. The issue stemmed from a naming conflict between XML templates, preventing the totals from being correctly displayed. The fix ensures that users can now see the complete timesheet totals for each task.
Original PR description
Issue: ---------------------------------------- The totals aren't displayed after the timesheet list on portal. Steps to reproduce: ---------------------------------------- - Have Timesheet and Project installed, with task having timesheet - Go on the Portal page, then "My Tasks" - Click on a task having several timesheets - The list of timesheet shows but not the totals. Cause: ---------------------------------------- This commit f84d46d8e99199c64f97b6a59247875bd32b0f91 separated the timesheet list and the timesheet totals into two different XML templates. The template with only the list of timesheet has the same name as the previous template containing both the list and the totals. So if the `t-call` aren't updated, the totals disappear from `saas-19.1` to `saas-19.2`. Solution: ---------------------------------------- Call `portal_timesheet_table_with_total` instead of `portal_timesheet_table`. opw-6247177 Forward-Port-Of: odoo/odoo#269446
This update fixes an issue where a second stock valuation entry was created when a repair order was finished and then a quotation or invoice was generated. This prevented accurate accounting records and potential discrepancies. The fix ensures that valuation entries are only created once for a product linked to a repair order.
Original PR description
When finishing a repair order a stock valuation entry is created for the product used. If you then make a quotation and invoice it another stock valuation entry would be created for the same product.…
When finishing a repair order a stock valuation entry is created for the product used. If you then make a quotation and invoice it another stock valuation entry would be created for the same product. Steps to reproduce: ------------------- * Create a category using FIFO and real time valuation * Create a product using this category and set it's cost to 5€ * Set some on hand quantity for the product * Create a repair order and add the product with the "Add" option * Finish the repair order > Observation: At this point you should have a valuation entry in the accouting app * From the repair order create a quotation and invoice it > Obesrvation: If you check the accounting entries again you will see a second valuation entry Why the fix: ------------ When checking if the line is eligible for valuation we make sure that if it is linked to a repair order, this repair order should not have any accounting entries linked to it. opw-5429996 Forward-Port-Of: odoo/odoo#254468
This update resolves an issue where PDF links within the Odoo viewer were not functioning correctly. The fix adjusts the layering of elements to ensure clicks are properly directed to the PDF links, improving the user experience when viewing documents with internal and external links. This ensures all links within the PDF viewer are accessible.
Original PR description
Version - 18.0 Steps to reproduce: 1. Upload a PDF document containing bookmarks and internal/external links 2. Open the document 3. Click on the links, some work and some do not Issue: `canvas_layer_0` is positioned over the PDF viewer with `z-index: 1`, intercepting clicks intended for PDF link annotations and making internal/external links unresponsive. The `.textLayer` already has `z-index: 2 !important` in iframe.css to prevent the same problem for text selection Fix: Added `z-index: 2 !important` to `.annotationLayer section` in `iframe.css` raising it above `canvas_layer_0`. Taskid = 6237688 Forward-Port-Of: odoo/enterprise#118040
A recent update removed the duplicate and delete buttons from the page properties dialog in the website settings. This change was caused by a renaming of a configuration property. This update restores these essential buttons, ensuring users can properly manage their static website pages.
Original PR description
Steps to reproduce: 1. Go to Website. 3. Open the page properties dialog of any static page. Issue: The duplicate and delete page buttons are missing from the page properties dialog, although they were available until version 19.0. Cause: After the changes introduced in [1](https://github.com/odoo/odoo/pull/220325/changes), the `buttonTemplate` prop was renamed to `buttonDialogTemplate`. However, this new prop was not handled in the page properties dialog, causing the buttons to disappear. task-6171493 Forward-Port-Of: odoo/odoo#262951
This update prevents unnecessary placeholder images from being sent during menu synchronization. By only sending actual image URLs when images are defined, we've reduced data transfer and improved the speed and efficiency of menu updates. This results in a smoother user experience.
Original PR description
This commit prevents placeholder images from being included in the menu sync payload and only sends `img_url` when an actual image is configured on the product or category. Task-6251430 Forward-Port-Of: odoo/enterprise#120075 Forward-Port-Of: odoo/enterprise#119482
This update streamlines the timesheet connection process by removing a redundant 'Close' button and automatically redirecting users to the timeline after a successful connection. This creates a smoother and more intuitive experience for users connecting to their Odoo Enterprise accounts.
Original PR description
- Remove 'Close' button from connection successful modal - Change Redirect users to http://localhost:5600/#/timeline after successful connection. task-6272843 Forward-Port-Of: odoo/enterprise#119800
This update fixes an issue where currency rates from the Bank of Mexico were incorrectly displayed. The change shifts the rate date by one day to align with the Bank of Mexico's data retrieval process, ensuring accurate currency conversions within the system. This improves the reliability of financial reporting.
Original PR description
banxico fetches the rates applied on the previous day, when we introduced using previous day's currency rate (here: https://github.com/odoo/odoo/pull/231948), we broke their logic. shift the rates date by one day to account for the change. task-6264708 Forward-Port-Of: odoo/enterprise#118999
This update optimizes the way Odoo checks access rights during reconciliation processes. Previously, a performance bottleneck existed when updating multiple reconciliation lines at once, leading to slower widget loading. This change improves the speed and efficiency of the reconciliation feature, particularly when handling large numbers of transactions.
Original PR description
When assigning a value in batch, the ORM doesn't manage to batch the call to `check_access` done in `write_batch`/`write_real` because each write is done individually when setting a value in the compute function. This field is especially annoying because it is read when opening the reconciliation widget on several lines. Forward-Port-Of: odoo/odoo#269601 Forward-Port-Of: odoo/odoo#269063
A bug preventing users from submitting WhatsApp template approvals with image headers has been resolved. This update corrects a technical issue related to how image data is processed, ensuring template submissions now function correctly. This improves the WhatsApp template approval workflow.
Original PR description
Currently an error occurs when the user tries to submit a WhatsApp template for approval with a header type image. Steps to produce an Error: - Install the whatsapp module - Create a new WhatsApp…
Currently an error occurs when the user tries to submit a WhatsApp
template for approval with a header type image.
Steps to produce an Error:
- Install the whatsapp module
- Create a new WhatsApp template as below
- Header Type = `Image`
- Upload any image in `Template Static Header`
- Fill in required fields
- Error occurs when click `Submit for Approval`
Error `TypeError: object of type 'LocalBinaryFile' has no len()`
This happens because of the recently refactored changes with [1]
`attachment.raw` now contains a `LocalBinaryFile` object instead
of a raw binary value. As a result, using the object directly in the
request at code line[2] (data) causes an error.
This commit fixes the above error by using `attachment.raw.content`,
which passes the actual image binary content in the request instead
of the `LocalBinaryFile` object.
[1]: https://github.com/odoo/odoo/commit/41fe2ebdb9cc37341362d7af829c087a5f72f9f1
[2]: https://github.com/odoo/enterprise/blob/28bd32718cd147093c9d56d79dce87ff32d44508/whatsapp/tools/whatsapp_api.py#L56
Sentry-7516083183This update resolves an issue preventing users from successfully posting LinkedIn updates with images. The fix corrects a technical error related to how image data is handled, ensuring seamless image uploads and post creation. This improves the LinkedIn integration for our users.
Original PR description
Currently an exception is generated when the user tries to create a Linkedin post with an image. Error: `TypeError: object of type 'LocalBinaryFile' has no len()` This happens because the recently refactored changes with [1] `image_id.raw` now contain a `LocalBinaryFile` object instead of a raw binary value. As a result, using the object directly in the request at code line [2] (`image_data`) causes an error. This commit fixes the above error by using `image_id.raw.content`, which passes the actual image binary content in the request instead of the `LocalBinaryFile` object. [1]: https://github.com/odoo/odoo/commit/41fe2ebdb9cc37341362d7af829c087a5f72f9f1 [2]: https://github.com/odoo/enterprise/blob/f6b6039b15ba17c293dcbfb46767a75475d4ce18/social_linkedin/models/social_account.py#L434 Sentry-7491355475
This update fixes a misleading warning message displayed in Odoo Enterprise's expense settings. The issue occurred when the 'Expense Card' was unchecked, even if Stripe issuing was supported for the company's location. Now, the system correctly checks the company's fiscal country to determine Stripe issuing support, ensuring accurate messaging.
Original PR description
In the Expense settings, under 'Expense Card', the warning 'Stripe issuing is not yet supported for your localization' was displayed when the checkbox 'Expense Card' was unchecked, even if the stripe issuing is supported by the current localization. We now use the fiscal country id of the company to check if the company's country supports stripe issuing. task-6253582 Forward-Port-Of: odoo/enterprise#118654
This update resolves an issue causing tracebacks in Firefox (Gecko-based browsers) when loading assets within iframes used in mass mailing processes. The fix prevents errors from propagating when iframes are unexpectedly removed from the page, ensuring a smoother user experience for Odoo users.
Original PR description
Loading assets bundles into an iframe requires the iframe to be connected (present in the DOM) at time of insertion. However, it can happen that iframes are removed from the DOM before all their…
Loading assets bundles into an iframe requires the iframe to be connected (present in the DOM) at time of insertion. However, it can happen that iframes are removed from the DOM before all their assets have loaded in. In these instances, errors from failed bundle loads will turn into tracebacks. This is generally not an issue in Chromium-based browsers as iframes do not fire a load event if they are disconnected; however, in Gecko-based browsers, this can happen. As such, mass_mailing users using Firefox currently receive a systematic traceback, as the CSS file "mass_mailing.assets_inside_builder_iframe.css" will not load. Steps to reproduce: - Use Firefox (or a Gecko-based browser) - Open a new mailing - Select the Events theme and make an edit (add a space...) - Save the mailing - Wait for 23 seconds The bug may be non-deterministic. Fix: Errors during the iframe load process will no longer bubble up if their iframe is disconnected when the error occurs. task-6293998 Co-authored-by: Damien Abeloos <abd@odoo.com> Forward-Port-Of: odoo/odoo#269324
This update fixes an issue where the shop floor displayed component quantities with excessive decimal places, leading to inaccurate readings. The fix addresses a floating-point calculation error that occurred when combining quantities from multiple lots, ensuring more precise and reliable data display.
Original PR description
**Issue** In the shop floor, floating-point values may display excessive decimals. **Steps to reproduce** - Create a BoM for a product, with a component tracked by lots - Set the component to be…
**Issue** In the shop floor, floating-point values may display excessive decimals. **Steps to reproduce** - Create a BoM for a product, with a component tracked by lots - Set the component to be consumed in a work order operation - Create several lots for the component, per ex 2: - LOT01 with 16.528 units - LOT02 with 10,000.00 units - Create an MO for 220.800 units of the finished product - Click on the shopfloor icon - Click to register the component consumption for the component. - Choose the first lot - Then choose the remaining units from the second lot -> This will display the quantity consumed as 220.79999999999998, even if the decimal accuracy is set to only 2 digits. **Cause** Since, there are 2 `moveLines`, one for each lot, the getter `quantityDone` add 2 floating point together: https://github.com/odoo/enterprise/blob/d7ab7ee1287342638006e290ede20b955aae8370/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L63-L69 inducing a floating-point precision error. The result is rendered directly in the XML template: https://github.com/odoo/enterprise/blob/d7ab7ee1287342638006e290ede20b955aae8370/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.xml#L8-L14 without rounding. opw-6243804 Forward-Port-Of: odoo/enterprise#118976
This update corrects a bug where the sale order name was inconsistently generated due to interactions between the purchase and product matrix modules. The fix ensures the correct name is passed through the system, preventing assertion errors and maintaining data integrity. This resolves a technical issue impacting order naming.
Original PR description
**Step to reproduce** Reproducible in single app The "name" field make this assertion fails: ``` self.assertRecordValues(sale_order.order_line[0], [{ "product_id":…
**Step to reproduce**
Reproducible in single app
The "name" field make this assertion fails:
```
self.assertRecordValues(sale_order.order_line[0], [{
"product_id": no_variant_product_tmpl.product_variant_id.id,
"name": 'No Variant\nAttribute: Value 1',
```
**Observation**
The name will not be the same depending which app are installed, purchase_product_matrix, changes the name of the product if there is a attribute value of a never variant: https://github.com/odoo/odoo/blob/f399f99d4e0e562d25e1de32336e8d6a55199b9b/addons/purchase_product_matrix/models/purchase.py#L168-L174 Which will be passed to the purchase_order_line:
https://github.com/odoo/odoo/blob/f399f99d4e0e562d25e1de32336e8d6a55199b9b/addons/purchase/models/purchase_order_line.py#L630-L634 that will pass the information to the sale order:
https://github.com/odoo/enterprise/blob/bce04ce24b66fb1a2481274eb3aebdc30a62766e/sale_purchase_inter_company_rules/models/purchase_order.py#L114 https://github.com/odoo/enterprise/blob/bce04ce24b66fb1a2481274eb3aebdc30a62766e/sale_purchase_inter_company_rules/models/purchase_order.py#L125-L126
**Additional information**
Since this [commit](https://github.com/odoo/odoo/commit/b8ebb26553f8170061debc7532606fd4777f0fcd#diff-5684edced9bdfc98021a85de4c6cdf691ea7add74e56ab50334a1d7db9ef4224R90) product_no_variant_attribute_value_ids was directly added in the purchase module.
breaking commit : https://github.com/odoo/enterprise/commit/bf286a0005b8e22ffa717419cd2dfacff861a265
runbot-242362
Forward-Port-Of: odoo/odoo#268016A recent issue preventing the 'See employee progress bar' tour from running correctly has been resolved. The fix addresses a dependency on a specific module installation and ensures the necessary steps are completed before progress bars are displayed, improving tour reliability.
Original PR description
The tour relied on the chatter loading to know when the page was done loading. Unfortunately, the chatter on that model is only added if planning_field_service is installed, so the test fails in single module installs. The "See employee progress bar" then failed because some employees do not have an email adress but we do not close the employee_no_email_list_wizard modal before checking the progress bars. We now click on action_send before the failing step. runbot-938958 Forward-Port-Of: odoo/enterprise#118492
This update resolves an issue causing excessive logging in Odoo when handling attachments created by external systems. By returning 'None' when attachment data is missing, the system avoids unnecessary error handling and log spam, primarily impacting integrations like EDI connectors. This improves overall system stability and performance.
Original PR description
Return None when datas is empty alongside the existing mimetype check. Avoids unnecessary exception handling leading to logspam for URL type attachments where binary data is unavailable. This issue is only reproducible programmaticaly as the mimetype is not available with url type attachment in Odoo. Thus, it's a problem that only impact third party integrations, EDI connectors or any workflow that creates ir.attachment records directly. opw-6010528 Forward-Port-Of: odoo/enterprise#116080 Forward-Port-Of: odoo/enterprise#113396
This update resolves a visual glitch in the chatter interface where an empty rectangle appeared next to log notes during editing. The issue stemmed from a system that remembered the last position, causing problems when scrolling. This fix ensures suggestions are displayed correctly regardless of scrolling, improving the user experience.
Original PR description
# How to reproduce - Go into any form view of a model with a chatter (e.g. Quotation) - Add multiple long log notes. You need to be able to scroll enough to not see the last log note - Click edit on…
# How to reproduce - Go into any form view of a model with a chatter (e.g. Quotation) - Add multiple long log notes. You need to be able to scroll enough to not see the last log note - Click edit on the last log note - Scroll down to the bottom # The problem An empty rectangle is displayed next to the log note in edit mode. # Cause The rectangle comes from the NavigableList Component, which is the list that displays suggestions when typing things like "@" or "#" : https://github.com/odoo/odoo/blob/1fd44c3bb11a79d5b6aa72bf7de5a83e6c45be46/addons/mail/static/src/core/common/composer.xml#L137 This components uses the `usePostion()` hook, which purpose is to try to find the most appropriate place to put the element. It will try different postions (e.g. on the left, below, above, etc.) and will pick the most appropriate one. It will then adjust the element's style to position it correctly. It is possible to ask for a preferred position using the options given to the hook. This position will be prioritized over the others if it is suitable. In the case of the NavigableList of the chatter, we give it either 'bottom-fit' or the 'top-fit' positions, wich means it will prefer to be displayed above or below the message : https://github.com/odoo/odoo/blob/dd84309df7fd39e9e97ed02d135d25b211085135/addons/mail/static/src/core/common/composer.js#L449-L459 But in our case, when we scroll back up, the position of the rectangle stays on the left, even though the below space is available. That is because of this commit that introduced a memorization of the last solution : https://github.com/odoo/odoo/commit/b2b8d2dbb8396d86492a3089db9b1b1545c8f13b https://github.com/odoo/odoo/blob/f2434aac74324a65ccd81aa18c7b0e8318e59fde/addons/web/static/src/core/position/position_hook.js#L59-L61 This means that when we scroll down, the bottom positions fails and so the left one is defaulted to. Since the position is memorized, it stays on the left. The issue with this left position is that another commit introduced some logic that made it so if the position is not "top" or "bottom", then we set the element's height to some value : https://github.com/odoo/odoo/commit/702748e2c8e895d372d07f9aeff273282d1b1a99 https://github.com/odoo/odoo/blob/f2434aac74324a65ccd81aa18c7b0e8318e59fde/addons/web/static/src/core/position/utils.js#L120-L124 And setting the height of the NavigableList makes it so it displayed even when there are no suggestions inside, because the hiding mechanism of the suggestion list relies on the fact that when there are no suggestions, the div is empty and has no height, so it is hidden. # Propose solution We introduce a settings in the options that will allow to skip the memorization of the last position. Since the left position will never be set in the options, no height will be defined. opw-6172407 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262822
This update corrects a labeling inconsistency in the Odoo purchase module. The 'incoming' button has been updated to 'purchase orders' for better clarity and user understanding. This change ensures users can easily identify and utilize the button's function.
Original PR description
Fix label on incoming purchases smart button. "sales order" -> "purchase orders" Forward-Port-Of: odoo/odoo#261254
This update resolves a bug where form updates triggered by changes in record IDs caused errors. Now, the system gracefully handles record ID changes, preventing crashes and ensuring data integrity when saving new forms. This improves the stability and reliability of the Odoo application.
Original PR description
* Open a new record form (the `onchange` RPC is cached). * Open a second new record form (it uses the cached `onchange` RPC). * Save the record before the `onchange` RPC returns. Before this commit, a race condition caused an error to be raised. When `web_save` is executed, it updates the record configuration with the new `resId` without reloading the view. When the pending `onchange` RPC finally returns, the cache callback misinterprets the data as a `web_read` result instead of an `onchange` result due to the updated ID, triggering a crash. Now, the callback safely does nothing if the resId has changed since the request was sent. runbot-243200 Forward-Port-Of: odoo/odoo#269524 Forward-Port-Of: odoo/odoo#268884
This update resolves a technical issue that caused the account reports audit tour to fail in complex Odoo environments. Specifically, the tour now waits for the correct Kanban view to be active before opening the necessary financial reports, ensuring a smoother and more reliable user experience.
Original PR description
The account_reports_audit tour was failing at the "Balances" button step due to a race condition in the preceding steps. In environments with many modules, the "Open the working file" step was triggered prematurely while still on the return checks view, because its selector was too broad. This commit narrows the selector for "Open the working file" to ensure it only triggers once the Kanban view is actually active. [runbot-938920](https://runbot.odoo.com/odoo/runbot.build.error/938920) Forward-Port-Of: odoo/enterprise#118346
This update corrects a previous issue where invoices generated from the Odoo website's e-commerce orders were incorrectly set to be CFDI public documents. Now, invoices for website orders will only be CFDI documents when explicitly required, ensuring compliance and streamlining the order process.
Original PR description
There is no reason why we would always cfdi to public when creating orders from the e-commerce. When the customer give all their info, the invoice should not be cfdi to public. opw-6180766 Forward-Port-Of: odoo/enterprise#119442 Forward-Port-Of: odoo/enterprise#116061
This update resolves a bug preventing the daily sales report from displaying its title correctly when the Colombian EDI module is active. The change ensures compatibility with a related report template, and also corrects a previous issue where the report would render without a title when the Colombian module wasn't installed.
Original PR description
The daily report template was replacing `//h2[@id='daily_report_title']` entirely, removing the node from the XML source. This caused `pos_hr.single_employee_sales_report` (a primary template that applies its own xpaths against the same patched base) to crash at compile time since its xpaths could no longer find that node. Switch from `position="replace"` to `position="attributes"` + `position="after"`: the h2 stays in the XML source at all times so pos_hr's xpaths always resolve, while the original title is hidden at render time via t-if when CO EDI is enabled and the Colombian content is inserted as a sibling after it. As a side effect, this also fixes a pre-existing bug where installing the module with DIAN disabled would render the daily report with no title at all. opw-6265637 Forward-Port-Of: odoo/enterprise#119668 Forward-Port-Of: odoo/enterprise#119003
This update resolves a visual issue in dark mode and corrects a functional error within the Gantt chart for holiday scheduling. Specifically, the selection process is now more intuitive, allowing users to select multiple holiday periods directly, improving the overall user experience.
Original PR description
- changed selected value in the view to be number of selected cells instead of number of selected records - fixed a visual bug in dark mode where the create popup has ugly background task-id: 6124765 Forward-Port-Of: odoo/enterprise#116229
This update resolves an issue where thumbnails weren't automatically generated when attaching documents to messages within the Composer. The fix ensures that thumbnails are now correctly created, improving the user experience when sharing documents. This enhancement supports seamless document management within the Odoo platform.
Original PR description
When attaching a documents to a message in the composer, the thumbnail was not generated. This commit fix this issue. Task-5096039 Forward-Port-Of: odoo/enterprise#116188
This update fixes a technical issue where IoT polling requests were failing and displaying error messages. The change ensures that all listening requests are handled, preventing these failures and improving the reliability of the IoT service. This resolves a potential disruption to data collection.
Original PR description
We were not awaiting the listening request in every case, making poll requests failures display tracebacks. We now await in any case to avoid this.
This update simplifies error codes within the l10n_fr_reports module. Removing specific error messages related to subscription checks has resulted in all errors now appearing as internal errors, without detailed information. This change aims to streamline error handling internally.
Original PR description
This commit: https://github.com/odoo/enterprise/commit/23afa6f2520a676dcb4cd94867065f1be03708bc change a bit the error codes but removed the ones from the check subscription. By doing so, all the error from that wrapper will give an internal error, and no other info on the error. no task id Forward-Port-Of: odoo/enterprise#120286
This update resolves an issue where downloading ETA invoices could cause a JSON decoding error. A recent change introduced a workaround, but this new fix adds a crucial catch block to properly handle this error, ensuring invoices download reliably. This improves the stability of the l10n_eg_edi_eta module.
Original PR description
When we download the ETA invoice PDF, a JSONDecoderError can happen when calling the json() method on the request. This error is properly caught by Odoo : https://github.com/odoo/odoo/blob/7a9a340e0dbac470c4bea3f8ce8a32e55f3e82e6/addons/l10n_eg_edi_eta/models/account_edi_format.py#L58-L60 However, the following commit introduced a monkeypatch to handle errors when the simplejson library is installed : 2435fe76eec1fc4320ef71726fc7f16ece653a32 If we meet the conditions, the original error is replaced by a json.JSONDecodeError which is not caught during the previous process. We propose to add this error to the catch block. This modification was inspired by the commit d483dac144a9caf84c44b9d8d394ea327ca87cfe. opw-6266862 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#268309
This update fixes a previous issue where sales employees transitioning to non-commission roles incorrectly accrued commission losses for public holidays and sick time. Now, employees in non-sales positions will no longer be impacted by these incorrect commission calculations, ensuring accurate payroll processing. This improves the reliability of the HR payroll module.
Original PR description
If a salesman moves to another job that doesn't pay commission, he shouldn't have loss on commissions for public holidays and sick time off. Forward-Port-Of: odoo/enterprise#120386
This update resolves a technical issue that caused tracebacks in Point of Sale (PoS) when testing LNA with IoT printer configurations. The fix ensures the IP field is properly defined, preventing errors and improving PoS stability. This addresses a known problem impacting printer connectivity.
Original PR description
When testing LNA using the LNA button in the navbar, if the printer configured is of type IoT, the IP field is undefined, and the PoS displays a traceback. We added a guard to return `false` when the IP is not defined. see odoo/enterprise#120273
This update ensures the LNA button in the POS interface correctly tests functionality for IoT Boxes. Previously, the button wasn't properly verifying LNA status, now a status action is sent when LNA is enabled, ensuring accurate IoT Box operation.
Original PR description
The LNA button in the POS navbar wasn't testing LNA for IoT Boxes. We now send a status action for IoT Boxes with LNA enabled. Forward-Port-Of: odoo/enterprise#119998
This update resolves an error that occurred when downloading the asset template in the Fixed Assets section. Previously, the system incorrectly checked for an account code, causing a technical error. Now, the system uses the asset account's display name, ensuring a smooth download process regardless of the account code's presence.
Original PR description
Currently, an error occurs when downloading the asset template. **Steps to Reproduce:** - Install the `account_asset` module without demo data. - Go to `Accounting` > `Configuration` > `Accounting` >…
Currently, an error occurs when downloading the asset template. **Steps to Reproduce:** - Install the `account_asset` module without demo data. - Go to `Accounting` > `Configuration` > `Accounting` > `Chart of Accounts`. - Open the `Fixed Assets` account, set a `Depreciation` value, and remove the `account code`. - Go to `Accounting` > `Accounting` > `Assets & Liabilities` > `Assets`. - Click `With our template` on the screen. `TypeError: startswith first arg must be str or a tuple of str, not bool` After this [recent commit], account codes became optional and can be removed. As a result, when the code is removed from the Fixed Assets account and when donloading the asset template, the system checks whether the account name starts with the account code [1]. Since the account code is `False`, it raises an error. This commit ensures that the check is only performed when the account code exists; otherwise, the account name is used directly for the asset account. [recent commit]: https://github.com/odoo/odoo/commit/c3313b336b9f1305c363097745926f2bdf61e277 [1]- https://github.com/odoo/enterprise/blob/421fce171dc158faa3b13406b6cea5c1c907ee49/account_asset/controller/asset_template_controller.py#L46-L49 sentry-7487406857
This update now limits the employees assigned to work orders based on the workcenter's configuration. Previously, all employees could be assigned, but now only employees specifically authorized for that workcenter are selectable. This improves accuracy and control over work order assignments.
Original PR description
Add domain on `employee_assigned_ids` to restrict selectable employees based on the workcenter configuration. If `all_employees_allowed` is True, no filter is applied. Otherwise, only employees listed in `allowed_employees` are selectable. opw-6208602 Forward-Port-Of: odoo/enterprise#117876
This update prevents the 'Project: Task Rating Request' email template from disappearing when project stages are set to inactive. Previously, disabling ratings on the last stage would remove the template option, causing a frustrating user experience. This fix ensures the template remains available for selection, streamlining the rating process.
Original PR description
Currently, when the `rating_active` feature is disabled on the last project stage using it, the default 'Project: Task Rating Request' email template is automatically archived. This creates a UX issue where the template disappears from the "Rating Email Template" dropdown on the stage form, preventing users from selecting it. This commit resolves the issue by: - Setting `active="True"` by default on the XML template record. - Removing the background archiving logic from the `write` method of `project.task.type`. - Appending a check to `test_send_rating_review` to ensure the template remains active even when all stages in the database have ratings disabled. Task-6102227 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#264394
This update resolves an issue where the `google_address_autocomplete` widget remained editable even when set to read-only mode. The fix ensures the widget correctly displays the field's value when in read-only mode, improving usability and data consistency.
Original PR description
**Issue:** The `google_address_autocomplete` widget remained editable even when the view or field was set to `readonly`. **Solution:** Modified the `AddressAutoCompleteTemplate` to conditionally render the component. If `props.readonly` is true, the template now renders a `<span>` with the field value. Task~5182770 Forward-Port-Of: odoo/odoo#268109 Forward-Port-Of: odoo/odoo#260952
This update resolves an issue where the builder sidebar incorrectly displayed "Block" for website snippets. The fix ensures that snippet titles are accurately shown in the builder, improving usability and allowing users to easily manage their page content. This was caused by a change in the plugin's setup process.
Original PR description
\* = website ### Issue: When a page is created either through the configurator or from an existing page template, block-level snippets do not display the correct title in the builder sidebar.…
\* = website
### Issue:
When a page is created either through the configurator or from an
existing page template, block-level snippets do not display the correct
title in the builder sidebar. Instead, "Block" is shown for all
snippets.
### Steps to Reproduce:
- **Configurator:**
1. Install the website module or create a new website from Settings.
2. Complete all configurator steps. Do not use "Skip and start from
scratch".
- **Page template:**
1. Open the website and click the "New" button in the systray.
2. Click on "Page" and choose any template other than a blank page.
### Observed behavior:
The builder sidebar shows "Block" in the option container for all
snippets instead of their actual names.
### Reason:
Previously, just before the builder was opened, the `data-name`
attribute was injected through `_computeSnippetTemplates()` for any
snippet that did not already have it. This behavior was lost after the
plugin refactoring.
### Fix:
As before, we now inject the `data-name` attribute during builder setup
for snippets that do not already have it.
task-[6087348](https://www.odoo.com/odoo/all-tasks/6087348)
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#269287
Forward-Port-Of: odoo/odoo#259893This update fixes an issue where images in email marketing templates were stretched and distorted when paired with long text. By removing specific styling, images now maintain their natural aspect ratio and fit correctly alongside the text, ensuring a professional and consistent email design. This improves the overall visual quality of marketing campaigns.
Original PR description
The media list snippet forces the image to fill the height of its row. The image column carries align-self-stretch and the image carries h-100, so when the text next to the image is longer than the…
The media list snippet forces the image to fill the height of its row. The image column carries align-self-stretch and the image carries h-100, so when the text next to the image is longer than the image is tall, the row grows to fit the text and the image is stretched to that height (and cropped through object-fit: cover). The longer the text, the more the image is distorted. Drop h-100 from the image and align-self-stretch from its column in the s_media_list snippet and in the mass_mailing_themes templates that reuse it. With no forced height the image keeps its natural aspect ratio and the row height follows its content, so the image is laid out next to the text instead of being stretched to match it. Steps to reproduce: 1. Open Email Marketing and create a new mailing. 2. Select the Blogging template for the mail body. 3. In a media item, replace the text next to an image with a very long paragraph. => The image is stretched and cropped to match the height of the text. Ticket [link](https://www.odoo.com/odoo/project.task/5117571) opw-5117571 Forward-Port-Of: odoo/odoo#268675 Forward-Port-Of: odoo/odoo#238138
This update resolves an issue that caused UBL file imports to fail when a vendor bill contained an empty 'EndpointID' field. The fix ensures the import process is more robust and reliable, preventing errors during invoice processing. This improves the overall stability of our UBL integration.
Original PR description
**Description:** Importing a UBL file (vendor bill) fails if it contains an empty "EndpointID" node. It assumes the node always contains text content to sanitize, but if it is empty, it crashes with: AttributeError: 'NoneType' object has no attribute 'strip'. **Steps to reproduce:** 1. Import a UBL as a bill, with an empty EndpointID node of the other party. 2. The import fails with the AttributeError. opw-6246515 Forward-Port-Of: odoo/odoo#269028
This update fixes an issue where new contacts created without a parent record didn't automatically have a default language assigned. The change ensures that all contacts, regardless of their parent relationship, receive the correct language setting, improving data consistency and reporting accuracy. This resolves a previous bug impacting contact data.
Original PR description
Before this commit, when creating a new crm_lead in the form view, using the res_partner_many2one widget to "Create" or "Create and Edit" a new contact would generate a contact without a set language. This happens because _compute_lang in res_partner currently only runs when the res_partner has a parent_id. This fix allows _compute_lang to be run for res_partner records without a parent_id. This ensures that we properly assign a default language for new contacts, using the proper context or the database default. opw-6126637 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263440
This update simplifies invoice sending by automatically defaulting to the 'By Peppol' method only for customers in designated countries (GR, IT, PL, PO, RO). Previously, this setting was enabled by default for all customers, causing confusion and unnecessary notifications for users in these regions. This change streamlines the invoicing process and improves user experience.
Original PR description
Current behavior before PR: - If the customer has a valid Peppol endpoint, the 'By Peppol' invoice sending method is selected by default. - For countries like 'GR,' 'IT,' 'PL,' 'PO,' and 'RO,' peppol is not mandatory or not used for sending invoice. It brings noise and it bothers the users. Desired behavior after PR is merged: - The 'By Peppol' invoice sending method is set to true by default only for customers from PEPPOL_DEFAULT_COUNTRIES. Changes Implemented: - Moved the countries 'GR', 'IT, 'PL', 'PO', and 'RO' from PEPPOL_DEFAULT_COUNTRIES to PEPPOL_LIST. - Added condition to set 'By Peppol' invoice sending method to true when customer is from PEPPOL_DEFAULT_COUNTRIES. task-6072935 Forward-Port-Of: odoo/odoo#269417 Forward-Port-Of: odoo/odoo#262402