Daily updates from Odoo
Thursday, March 12, 2026
80 changes · saas-19.2
Resolved issues and error corrections
This update resolves a bug where typing in an empty HTML editor button would remove the button element entirely. The fix prevents the browser from replacing the link node during text input, ensuring the button remains visible and functional. This improves the user experience when editing content within the HTML editor.
Original PR description
Problem: On the website, typing inside an empty button removes the button element entirely. Cause: In `beforeinput` (when `ev.inputType === "insertText"`), we set the selection to `boundariesIn` of a link. When the browser then inserts the character, it replaces the link node, causing the button to be removed. Solution: In `FormatPlugin.onBeforeInput`, avoid setting the selection to `boundariesIn` of a link for `insertText` events. This prevents the browser from replacing the link element when typing. Steps to reproduce: - Open Website. - Drop a snippet containing a button. - Triple-click on the button content. - Press Backspace to empty it. - Type any character. - Observe that the button is removed. task-5949409 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a problem that occurred when loading the demo data for the 'account_asset' module. The fix corrects an error related to incorrect field definitions during demo data setup, preventing a data loading failure. This ensures demo data can be reliably loaded without disrupting the system.
Original PR description
This error occurs while loading the demo data for the `account_asset` module. Steps to reproduce: - Install `account_asset` module without demo data - Active debugger > Settings > load Demo data Traceback: `ValueError: Invalid field 'depreciation_model_id' in 'account.asset'` - The error occurs because `depreciation_model_id` is a field of the `account.account` model, but while loading the demo data we are defining it on the `account.asset` model in the `_get_demo_data_asset` [method]. - Another error occurs in the `account.depreciation.model` model because it does not have a field named `name`, the correct field is `display_name`. [method]: https://github.com/odoo/enterprise/blob/9d4424088bfda7e89d454a8bd642715a9281913d/account_asset/demo/account_demo.py#L37-L47 sentry-7321811436
A minor technical issue was resolved where an incorrect field was being used in the account online payment process. This prevented a system error and ensures data is processed correctly. The change improves system stability and reliability.
Original PR description
Due to an oversight during https://github.com/odoo/enterprise/pull/109070, the old field `sanitized_acc_number` was used instead of the new one `sanitized_account_number` This causes a traceback. No task ID
This update resolves an issue where order validation was sometimes skipped due to data serialization delays during the tour process. The change adds a mandatory step to select the invoice before order validation, ensuring invoices are correctly generated. Unnecessary tour steps have also been removed.
Original PR description
pos*: point_of_sale, pos_sale, l10n_sa_edi_pos, l10n_es_pos,l10n_be_pos_sale When invoice selection takes longer, and the order validation button is clicked immediately after, the tour may serialize data before the invoice field has settled. This can cause invoice generation to be skipped during order validation Since the delay between tour steps was removed, this commit adds an explicit step to ensure the invoice is selected before validating the order. Additionally, removed unused tour `PosSettleAndInvoiceOrder` Task-5897375 Err-237600, 238502 Related-https://github.com/odoo/enterprise/pull/106863
This update resolves a bug where order validation was sometimes skipped due to data serialization issues during POS tours. The change adds a required step to ensure the invoice is selected before order validation, guaranteeing accurate invoice generation and order processing. This improves the reliability of the POS system for users.
Original PR description
pos*: l10n_ec_edi_pos, l10n_it_pos When invoice selection takes longer, and the order validation button is clicked immediately after, the tour may serialize data before the invoice field has settled. This can cause invoice generation to be skipped during order validation Since the delay between tour steps was removed, this commit adds an explicit step to ensure the invoice is selected before validating the order. Task-5897375 Err-237600, 238502, 238503, 238504 Related-https://github.com/odoo/odoo/pull/247770
This update ensures that customers receive a receipt email only after their online payment for self-orders has been successfully validated. Previously, receipts were sent prematurely, leading to customer confusion. This change improves the customer experience by aligning receipt delivery with actual payment confirmation.
Original PR description
In self-order with online payment, the receipt email could be sent when the order was created (before payment validation), which confirms the order too early for customers. This change ensures receipt sending is aligned with actual payment success in the online self-order payment flow. Steps to reproduce: ------------------- * Configure self-order with a preset that has a receipt mail template. * Place a non-zero self-order using online payment and reach the payment step. * Check customer mailbox before validating payment. > Observation: A confirmation email can be sent before the payment is confirmed. Why the fix: ------------ Receipt emails must reflect a successful payment outcome, not just draft order creation. The online self-order payment success path now triggers receipt sending after the order transitions from draft to paid/done, preventing premature emails. opw-5938299 Forward-Port-Of: odoo/odoo#252797 Forward-Port-Of: odoo/odoo#251220
This update prevents the deletion of email template attachments when they are removed from the mail composer. Previously, removing an attachment would permanently remove it from all future emails. The fix ensures attachments remain associated with templates, maintaining consistent email content.
Original PR description
**Step to reproduce:** 1. Install `sale_management` 2. Open any email template (e.g., Sale: Order Confirmation). 3. Add an attachment to it 4. Create a Sale Order, confirm it, and click "Send by…
**Step to reproduce:** 1. Install `sale_management` 2. Open any email template (e.g., Sale: Order Confirmation). 3. Add an attachment to it 4. Create a Sale Order, confirm it, and click "Send by Email". 5. In the mail composer, remove the template attachment **Issue:** - The removed attachment is deleted from the database (`ir.attachment`). Consequently, the attachment is permanently removed from the source Email Template and will not appear in future emails. **Cause:** - The `onFileRemove` function in `MailComposerAttachmentList` calls the `unlink` method of the `attachmentUploadService` for every file removed, without considering the existing template attachment. **Solution:** 1. Update `mailComposerAttachmentList` to include `res_model` in `relatedFields` so it is fetched from the server. 2. In `onFileRemove`, check the `res_model` of the attachment. 3. If the `res_model` is not "mail.compose.message", skip the database deletion (unlink) and only remove it from the composer view. opw-5163679 Forward-Port-Of: odoo/odoo#250086 Forward-Port-Of: odoo/odoo#238692
This update resolves an issue where clicking images with 'Pop-up on Click' enabled would cause a website crash. The fix ensures that the image gallery code initializes correctly, preventing errors when images aren't part of a carousel. Additionally, the popup functionality has been restricted to product images.
Original PR description
Steps to produce: --- - Install `website_sale` module. - Go to website > open editor. - Add an image snippet to the homepage. - Click on the image and enable `Pop-up on Click`, then save. - Click on…
Steps to produce:
---
- Install `website_sale` module.
- Go to website > open editor.
- Add an image snippet to the homepage.
- Click on the image and enable `Pop-up on Click`, then save.
- Click on the image.
Traceback:
---
`TypeError: Cannot read properties of undefined (reading 'length')`
Root cause:
---
- In the `setup` method, when the image is not part of a carousel,
the element `.carousel-indicators` does not exist. As a result,
`indicatorEl` is null, and the guarded block(at [1]) is skipped.
Because of this, `this.liEls` is never initialized.
- Later, when the `onSlidCarousel` method is executed,
its internal condition evaluates and find `liEls` as null and
then `hide` method is called(see [2]).
- Inside the `hide` method, the code attempts to iterate
over `this.liEls`(see [3]).
Solution:
---
- Initialized `liEls` in `setup()` to ensure it is always defined.
- Added a length check in `onSlidCarousel()` to execute the logic
only when `liEls.length > 0`.
- This prevents this.page from being computed using invalid
values and avoids it being set to `NaN`.
- Additionally, as requested by the boje(po), hide the popup
on click setting on product images.
**Alternative approaches:**
1. We can also call the `onSlideCarousel` method from `setup`
when multiple images are present.
2. Also, we can add a simple check inside the `onSlideCarousel`
method to ensure that `liEls` is defined before proceeding.
[1]: https://github.com/odoo/odoo/blob/945f44e55f9a67b0744a183200de728b00202b1c/addons/website/static/src/snippets/s_image_gallery/gallery_slider.js#L31-L57
[2]: https://github.com/odoo/odoo/blob/945f44e55f9a67b0744a183200de728b00202b1c/addons/website/static/src/snippets/s_image_gallery/gallery_slider.js#L144-L152
[3]: https://github.com/odoo/odoo/blob/945f44e55f9a67b0744a183200de728b00202b1c/addons/website/static/src/snippets/s_image_gallery/gallery_slider.js#L119-L120
opw-5921123
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#247936A minor warning appearing on Odoo website pages related to URL hashes has been fixed. This change ensures a smoother user experience by eliminating a potential technical issue that wasn't impacting functionality. The fix improves website stability and reliability.
Original PR description
Since [34df6f8d], a warning `Empty string passed to getElementById().` appears on every website page when there is no hash in the URL. That's not the case anymore after this commit. [34df6f8d]: https://github.com/odoo/odoo/commit/34df6f8d6efc879bef00228b19df04db6c884089 Forward-Port-Of: odoo/odoo#252181
This update resolves an issue where users could inadvertently add partners from different companies when managing multiple companies within Odoo. This change ensures partners are correctly associated with their respective companies, improving data accuracy and streamlining accounting processes. It's a necessary fix for reliable multi-company operations.
Original PR description
Before this commit, it was possible to add a partner that was from another company when multiple companies were selected. task-5941113 Forward-Port-Of: odoo/enterprise#108048 Forward-Port-Of: odoo/enterprise#107546
This update resolves a visual issue where list views with search panels (like Rental and Employees) would sometimes display a horizontal scrollbar. This change ensures that list views with search panels display content correctly on mobile devices, providing a consistent and user-friendly experience. It corrects a minor display problem that could have impacted usability.
Original PR description
This PR aims to fix the horizontal scroll overflow which only affects list views with a search panel (e.g. Rental, Employees, etc.). task-5888678 | Before | After | |--------|--------| | <img width="1125" height="2436" alt="Screen Shot 2026-02-19 at 15 29 15" src="https://github.com/user-attachments/assets/b89d2979-78a8-4c58-8f7f-7dedb6fc8fff" /> | <img width="1125" height="2436" alt="Screen Shot 2026-02-19 at 15 30 10" src="https://github.com/user-attachments/assets/0989b6e7-ef91-43b5-8df5-c27696d43f65" /> | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252362 Forward-Port-Of: odoo/odoo#249506
This update corrects a technical issue preventing electronic invoices under the RIMPE Emprendedor regime from being properly processed. The change ensures the correct string value is used, aligning with SRI specifications and resolving a validation error during the invoice signing process. This ensures compliance and accurate invoice generation for Ecuadorian businesses.
Original PR description
Corrected the hardcoded string for the RIMPE Emprendedor regime to match the SRI structure According to SRI technical specifications, the <contribuyenteRimpe> tag only accepts two specific values:…
Corrected the hardcoded string for the RIMPE Emprendedor regime to match the SRI structure According to SRI technical specifications, the <contribuyenteRimpe> tag only accepts two specific values: CONTRIBUYENTE RÉGIMEN RIMPE (Fixed value) CONTRIBUYENTE NEGOCIO POPULAR - RÉGIMEN RIMPE Steps to reproduce: Install l10n_ec_edi module Go to Settings > Invoicing > Ecuadorian Localization In Electronic Invoicing > Regime, select rimpe_emprendedor In Electronic Invoicing > Regime, configure a SRI Connection Post an customer invoice **Validation error occurring during the electronic signing process (using .p12 certificates):** `35 - Se encontró el siguiente error en la estructura del comprobante: cvc-pattern-valid: Value 'CONTRIBUYENTE EMPRENDEDOR - RÉGIMEN RIMPE' is not facet-valid with respect to pattern 'CONTRIBUYENTE RÉGIMEN RIMPE|CONTRIBUYENTE NEGOCIO POPULAR - RÉGIMEN RIMPE' for type 'contribuyenteRimpe'.. - ARCHIVO NO CUMPLE ESTRUCTURA XML - ERROR ` Forward-Port-Of: odoo/enterprise#109147
This update corrects a bug where users were seeing all company documents instead of just their own employee documents when using the documents smart button. The fix restores the intended behavior for companies without HR document centralization enabled, ensuring employees only access their own files. This resolves a previous issue impacting document organization.
Original PR description
Steps: - uncheck the "Human Resources" file centralization option - go to an employee, click the documents smart button -> You see every documents, not only the ones from the employee PR https://github.com/odoo/enterprise/pull/93782 aimed at restoring the previous behaviour of the employee documents button and accesses for companies without the hr documents settings enabled, but forgot the domain on the employee smartbutton action. opw-5857914 Forward-Port-Of: odoo/enterprise#107224
This update reduces the visual prominence of reply notifications in conversations with many replies. Previously, overly visible 'reply' text made long threads feel overwhelming. Now, the text is less intrusive and the hover effect is enhanced for better usability.
Original PR description
Before this commit, conversations that had a lot of replies were quite exhausting. This comes from the visual of "reply" text that had its text that is too visible, contributing to having a feeling that there's too much text on the screen. This commit fixes the issue by reducing the visibility of reply to part, so that it's easier to read conversations with lots of reply-to. Opacity has been reduced to keep the reply-to content recognizable enough, and this reduced visibility is canceled on mouse-hover, also making the hover effect on reply-to more apparent. Before / After <img width="604" height="520" alt="Screenshot 2026-02-27 at 19 06 03" src="https://github.com/user-attachments/assets/04a118bc-5fc0-47d6-ad62-3b7e26f835da" /> <img width="604" height="525" alt="Screenshot 2026-02-27 at 19 05 50" src="https://github.com/user-attachments/assets/37974f2c-054c-44bc-bf9a-044825908abc" /> Forward-Port-Of: odoo/odoo#251295
This update resolves an issue where self-order tests were failing due to a product's 'available in pos' status not being correctly set. This prevented products from loading properly in the self-ordering frontend, causing test failures. The fix ensures accurate product availability information, improving test reliability and preventing potential issues in the self-order system.
Original PR description
In some self order tests, available in pos was not set to true which could cause some errors in the tests as some products were not loaded in the self frontend. runbot-error: 241086 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252985
This update resolves an issue where the system incorrectly interpreted date columns in import files. Specifically, it fixes a problem where dates like '2500/1222' were mistakenly identified as '%Y.%m.%d' format, causing import errors. This change ensures that import files are processed correctly, preventing data import failures.
Original PR description
## Description of the issue/feature this PR addresses: If you try to import an excel sheet for example with these column on sale order, but the issue is at every model: (this is an example)…
## Description of the issue/feature this PR addresses: If you try to import an excel sheet for example with these column on sale order, but the issue is at every model: (this is an example)  First column: Client ref Second column: committment date Third column: Customer ## Current behavior before PR: When you upload the file to import, the extract_header_types calls _try_match_date_time that try to guess the date column. The first column makes the _try_match_date_time to guess that the format is %Y.%m.%d format . This is an error because that column does not contain a date . The reason is that check_patterns when convert the pattern to reg ex using `def to_re(pattern):` on base_import/base_import.py, does not escape the "." so it works as "every char" wildcard character on regex . ## Desired behavior after PR is merged: No error should appear and the correct date format from the right date column should be guessed --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252488 Forward-Port-Of: odoo/odoo#196477
This update resolves an issue where temporarily disabled products weren't appearing correctly in the self-order POS configuration. The fix ensures that product snoozes are now accurately reflected in real-time, based on updates from the cashier screen. This improves the accuracy of product availability displayed to the cashier.
Original PR description
The `pos_snooze_ids` was not included in the `load_pos_self_data_fields` so the field was not accessible in the config in self and it would not display the temporary disabled products. I added it now so that products will be disabled in real time based on updates from the cashier screen --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252686
This update ensures that when users send multiple messages in a live chat, only one channel is created. Previously, sending multiple messages could result in duplicate channels being formed. This change prevents channel duplication, streamlining the live chat experience for users.
Original PR description
Before this commit, sending multiple messages before the channel creation can result in multiple channels being created. It occurs because the post function is overriden to first persist the channel. When the persist call is still in progress, we shouldn't issue a new one. task-4756758 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#251596 Forward-Port-Of: odoo/odoo#250374
This update resolves an issue where Discuss calls could fail due to race conditions when retrieving channel data. By delaying the call until channel information is fully loaded, the system now reliably starts calls without encountering stale data and ensuring a smoother user experience. This fix was triggered by a test failure and improves overall call stability.
Original PR description
...in crosstab call test The "join/leave sounds are only played on main tab" test could race with the initial `channels_as_member` fetches triggered when opening Discuss in both tab Those fetches return full channel data, including `rtc_session_ids`. one of their responses could arive after the call had already progressed or ended and overwrite the state with stale RTC data Wait for `channels_as_member` to be fully processed after opening Discuss in each tab before starting the call. fix for: https://runbot.odoo.com/odoo/runbot.build.error/241061 Forward-Port-Of: odoo/odoo#253005
This update corrects an issue where late hours calculations were incorrectly applied to employees outside of Saudi Arabia. The fix now ensures that late hours visibility is only processed for employees within Saudi Arabian companies, improving accuracy and reporting for our SA clients. A new test case confirms this country-specific functionality.
Original PR description
Before this fix, the `_compute_l10n_sa_late_hours_visible` method was processing all attendance records regardless of the employee's company country. This caused issues for non-Saudi companies. Changes: - Filter attendance records to only process employees from Saudi Arabian companies (country_code == 'SA') - Set `l10n_sa_late_hours_visible` to False for non-SA attendances - Add `employee_id.company_id.country_id` to the compute dependencies - Add `string` attribute to `l10n_sa_expected_check_in` field - Add test case to verify late hours visibility is country-specific task-5491785 Forward-Port-Of: odoo/enterprise#104563
This update resolves an issue where Odoo invoices for Danish customers were incorrectly formatted according to Peppol standards. The change ensures compliance with `DK-R-013` by skipping the inclusion of PartyIdentification, preventing errors and improving invoice processing for Danish businesses using Peppol.
Original PR description
Currently, if a Danish partner has a reference set, Odoo adds it under PartyIdentification. This violates Peppol `DK-R-013`, which mandates using schemeID when PartyIdentification is used. Adding the Danish schemeID would also trigger another error, `PEPPOL-COMMON-R042`, as the organization number (CVR) must be included in the `_text`. Including schemeID seem therefore unnecessary since it will appear in CompanyID. Steps to reproduce: - Create a Danish company and enable Peppol - Create a Danish customer with a reference - Create an invoice and submit to Peppol, `DK-R-013` error occurs opw-5921602 Forward-Port-Of: odoo/odoo#251737
This update ensures that when a POS order is cancelled, the system accurately recalculates the outstanding payment amount. Previously, cancelled order lines were incorrectly included in payment totals, leading to inaccurate reporting. This fix prevents double-counting rolled-back payments, improving financial accuracy.
Original PR description
Add `pos_order_line_ids.order_id.state` to the depends of `_compute_pos_amount_unsettled` so that cancelling a POS order triggers a recompute. Also exclude cancelled order lines from `total_pos_paid` to avoid counting payments that were rolled back. opw-5997872 Forward-Port-Of: odoo/enterprise#109542
This update fixes an issue where currency exchange difference values were missing from DATEV exports. The fix adjusts how the export generates amounts, ensuring accurate reporting of exchange rates for DE company transactions. This improves the reliability of financial data sent to DATEV.
Original PR description
**Steps to reproduce: 1. Create DE company (EUR currency) 2. Add USD -> EUR exchange rates for XX/01/26 and XX/15/26 (XX is target month) 3. Install l10n_de_reports 4. Make sure bank journal has…
**Steps to reproduce: 1. Create DE company (EUR currency) 2. Add USD -> EUR exchange rates for XX/01/26 and XX/15/26 (XX is target month) 3. Install l10n_de_reports 4. Make sure bank journal has 'outstanding receipts' set for incoming manual payment [Accounting -> Config -> Journals -> Bank] 5. Create USD invoice for XX/02/26 and confirm it 6. Register a Payment for XX/16/26 and confirm it (you should see the exchange difference entry matched alongside the payment) 7. Go to [Accounting -> Reporting -> General Ledger] and export DATEV data **Description of issue: The currency exchange rate difference entries in the exported file are shown as 0 **Expected behavior: The actual currency exchange difference values should be displayed **Why this happens? The DATEV export currently sets the amount based on 'amount_currency'. For currency exchange difference entries, this value is 0.0 in the General Ledger, resulting in 0 values in the export. **The fix: Updated the logic to use the line balance when the entry is identified as a currency exchange difference. opw-5358954 Forward-Port-Of: odoo/enterprise#109655 Forward-Port-Of: odoo/enterprise#107268
This update adjusts the order in which taxes are processed for Mexican accounting (l10n_mx). Previously, the order caused incorrect tax calculations due to how taxes are prioritized. This change ensures accurate tax calculations, preventing potential financial discrepancies for Mexican users.
Original PR description
The current layout has the IEPS first, then IVA, and finally the Withholding, this will cause calculations to be wrong because of tax hierarchy. Most users are not aware that the tax order affects the calculation, so this would help prevent incorrect results. task-5247176 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252780
This update resolves an issue that occurred when users attempted to remove a company association from an expense record. The fix ensures the system handles company removal gracefully, preventing a technical error that could disrupt expense management. This improves the reliability of the expense tracking process.
Original PR description
Currently an error occurs when user tries to remove company on an expense. Steps to replicate: - Install `hr_expense` and create a new company. (make sure you have more than one company). - Create new expense and remove the value from company field. Error: `ValueError: Compute method failed to assign hr.expense(<NewId origin=7>,).is_editable` Cause: - Removing the company triggers the [compute] that skips the loop if company is not assigned [1], which causes this error. Solution: - Assign `is_editable` as False when company is false. [compute]: https://github.com/odoo/odoo/blob/43505c919e29065b04d4e9e0a66f38a13f42daed/addons/hr_expense/models/hr_expense.py#L304-L363 [1]: https://github.com/odoo/odoo/blob/43505c919e29065b04d4e9e0a66f38a13f42daed/addons/hr_expense/models/hr_expense.py#L326-L331 No ID --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241507
This update resolves a problem where Discuss Notifications sound settings weren't correctly applied after upgrading to version 19.1. The issue stemmed from a version comparison error related to the 'saas~' prefix. This change ensures notifications settings are properly updated during upgrades, maintaining expected functionality.
Original PR description
Before this commit, upgrade of local storage from 19.0 to 19.1 were not working. Steps to reproduce: - have DB in 19.0 with message sound "off" in Discuss Notifications settings - upgrade to 19.1 DB (or make a fresh 19.1 DB on same sub-domain) - log on this new DB => "message sound" settings is "on" when it should be "off". This happens because the server version is "saas~19.1" and the prefix `saas~` was not taken into account. As a result, the version `saas~19.1` was mistakenly considered as lower than `19.0`. This commit fixes the issue by omitting the prefix `saas~` in the utils function of version comparison, which is what is used by the local storage internal code to compare versions. Upgrade version has been bumped to `19.1.1` and upgrade scripts have their sub-version explicitly set to `19.1.0`, so that these scripts are run for versions equal or lower than `19.1.0`, meaning they re-run also for `19.1.0`. Task-6008166 Forward-Port-Of: odoo/odoo#252204
This update resolves an issue where incoming emails with attachments using the 'bin/plain' MIME type would cause the system to crash. The fix now gracefully handles this attachment type by falling back to a standard format, ensuring all emails are processed correctly and preventing disruptions to vendor bill creation.
Original PR description
When parsing incoming emails, mail.thread normalizes some malformed MIME types before calling part.get_content(). However, attachments using Content-Type `bin/plain` are not normalized. As a result,…
When parsing incoming emails, mail.thread normalizes some malformed MIME types before calling part.get_content(). However, attachments using Content-Type `bin/plain` are not normalized.
As a result, Python's email content manager raises KeyError('bin/plain') during parsing, which aborts the whole message processing. This prevents the incoming email from being processed, including vendor bill creation from email aliases.
Steps to reproduce:
- build an email with an attachment using Content-Type `bin/plain`
- parse it through `mail.thread.message_parse`
Before this commit, parsing crashes with KeyError('bin/plain').
This commit treats `bin/plain` like the other unsupported attachment MIME types already handled in stable, by falling back to `application/octet-stream`, allowing the message to be parsed and the attachment to be preserved.
opw-5439156
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#251440This update prevents installation errors related to PostgreSQL permissions. Previously, the system would fail if the PostgreSQL user lacked the necessary rights to create extensions. Now, the system checks if the extension is already installed before attempting to install it, reducing the need for extensive PostgreSQL user permissions.
Original PR description
[FIX] ai: test if pg_vector is installed before launching the create extension command
The command `CREATE EXTENSION IF EXISTS ...` require the postgresql user to have rights to use the command `CREATE EXTENSION`.
If the extension is already installed it will fail with a stacktrace because of inssuficient rights. `psycopg2.errors.InsufficientPrivilege`
With this PR we want to be able to install the module without giving too many rights to the postgresql user.
Forward-Port-Of: odoo/enterprise#109650This fix resolves an issue where the price calculation from a BOM was incorrect when the BOM was created for a product with multiple variants. The update ensures that work center efficiency is properly considered during the cost computation, leading to accurate pricing.
Original PR description
**Issue** Computing the price from BOM can be incorrect when the BOM is defined on a multi-variant product. **Steps to reproduce** - Create a product with several variants - Create a BOM for that…
**Issue**
Computing the price from BOM can be incorrect when the BOM is defined on a multi-variant product.
**Steps to reproduce**
- Create a product with several variants
- Create a BOM for that product without specifying the product variant
- Define an operation restricted to a specific variant V
- Associate the operation with a workcenter with:
- Non-null cost per hour (e.g. 100)
- Time efficiency lower than 100% (e.g. 50%)
- Go to the product page > Variants > variant V
- Click on "Compute price from BOM"
-> The result will be 100 instead of 200 in this example.
Please notice that the price is correctly computed in the BOM overview
**Cause**
Accessing the BOM triggers a `web_read` including `operation_ids`,
which requires computing `time_total`:
https://github.com/odoo/odoo/blob/233316f322d891ebaadb51412ea0df039bfd312a/addons/mrp/models/mrp_routing.py#L77
During this computation, the associated product is retrieved:
https://github.com/odoo/odoo/blob/233316f322d891ebaadb51412ea0df039bfd312a/addons/mrp/models/mrp_routing.py#L106
But since no product is given in the context and the BOM has been created without specifying the product variant
(`bom_id.product_id` is empty), then it retrieves all the product variant associated to the BOM, which leads to
arbitrary default value that ignores work center efficiency:
https://github.com/odoo/odoo/blob/233316f322d891ebaadb51412ea0df039bfd312a/addons/mrp/models/mrp_routing.py#L107-L111
While clicking on "Compute price from BOM":
https://github.com/odoo/odoo/blob/233316f322d891ebaadb51412ea0df039bfd312a/addons/mrp_account/models/product.py#L33
it will ultimately needs to compute the cost:
https://github.com/odoo/odoo/blob/233316f322d891ebaadb51412ea0df039bfd312a/addons/mrp_account/models/product.py#L74
which relies on `time_total`:
https://github.com/odoo/odoo/blob/233316f322d891ebaadb51412ea0df039bfd312a/addons/mrp/models/mrp_routing.py#L131
and since no context is provided, `time_total` is already in the cache, so the default value is used.
Please notice that in BOM overview, the problem does not occur because the provided context retriggers the compute method:
https://github.com/odoo/odoo/blob/233316f322d891ebaadb51412ea0df039bfd312a/addons/mrp/report/mrp_report_bom_structure.py#L806
https://github.com/odoo/odoo/blob/233316f322d891ebaadb51412ea0df039bfd312a/addons/mrp/report/mrp_report_bom_structure.py#L835
opw-5909570
Forward-Port-Of: odoo/odoo#248758This update corrects a previous issue where users with limited inventory access rights couldn't save new delivery records. The change ensures that access controls are properly enforced when saving stock moves, preventing errors related to data writing. This improves usability for all users, regardless of their access level.
Original PR description
### Step to reproduce: - Take a user with only basic inventory user access rights - Create a new delivery, add a stock move, try to save the record #### > Access error: Failed to write firld…
### Step to reproduce: - Take a user with only basic inventory user access rights - Create a new delivery, add a stock move, try to save the record #### > Access error: Failed to write firld stock.move.l10n_uy_edi_addenda_ids This flow is tested by the `test_basic_stock_flow_with_minimal_access_rights` test after installing the `l10n_uy_edi_stock` module. Cause of the issue: Since [19.0](https://github.com/odoo/odoo/commit/4a822785ca850c7ae5b21039536333276b2c61af) the read access right of the comodel is checked when writing on a many2many field. However, only the `account.group_account_invoice` does have read access on the `l10n_uy_edi.addenda` model: https://github.com/odoo/enterprise/blob/482b4564b3a81e914d6eead9a7b85a23b7cac3dc/l10n_uy_edi/security/ir.model.access.csv#L2 This is problematic as the `l10n_uy_edi_addenda_ids` field is added to the view even for users without read access rights on the comodel: https://github.com/odoo/enterprise/blob/482b4564b3a81e914d6eead9a7b85a23b7cac3dc/l10n_uy_edi/views/account_move_views.xml#L43-L53 Even if the field is invisible it is now part of the fields checked by the onchange and the values saved by the picking `web_save`. In particular, creating a new picking from the form view and saving the record will try to write an `[]` value on the `stock.picking` `l10n_uy_edi_addenda_ids` field and trigger the access error. runbot-240937 Forward-Port-Of: odoo/enterprise#109817
This update fixes a bug where the website's industry selection didn't correctly recognize capital letters or synonyms. The fix made the matching case-insensitive and simplified the synonym matching process, ensuring users can accurately select industries.
Original PR description
The industry highlighting to indicate what the user wrote match with the proposed industries was case sensitive, so the capital letters were not indicated as matching with lowercase letters. Fix: Added the flag "i" at the end of the regex to make it case-insensitive Also, in the case of the synonyms, the regex used was spliting on ",", "|" and space. The space spliting made matching a synonym sentence much more complicated. Fix: Deleted the space in the regex task-5066428 Forward-Port-Of: odoo/odoo#252447
This update resolves an issue preventing the activation of Point of Sale (POS) configurations when a POS session was already open. Previously, a session had to be closed before a new configuration could be applied. This change ensures smoother POS configuration management and avoids disruption for users.
Original PR description
Before this commit, it was not possible to activate a pos.config if there was an open session linked to it. This was a problem because it is only possible to close the session when the pos.config is active, and it was not possible to activate. opw-5964181 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250591
This update fixes a problem where invoices were incorrectly marked as coming from the company when forwarded bills included the company's email address. This ensures invoices are accurately attributed to the correct vendor, improving billing accuracy and reporting. The change was a simple bug fix.
Original PR description
Prevent setting the company's partner as the vendor for a forwarded bill when the body contains the company's email. Forward-Port-Of: odoo/odoo#252815
This update corrects a bug where employees were consistently shown the oldest payslip version. The fix directly passes the correct payslip version to prevent a race condition in the system's version calculation, ensuring employees always see the most up-to-date payslip information.
Original PR description
[FIX] hr_payroll: adjust proper version in payslip Bug reproduction: Select an employee that has at least 1 payslip already, go to employee tab -> smart button payslip -> then you are in list view of…
[FIX] hr_payroll: adjust proper version in payslip
Bug reproduction: Select an employee that has at least 1 payslip already, go to employee tab -> smart button payslip -> then you are in list view of payslips -> off cycle -> then your version is the first version of the employee, even though you are trying to create a payslip with the latest version of you.
Bug cause:
1 - Before version saas-19.2, date_from in hr_payslip is used to determine the version_id (in compute_version_id)
2 - When version>=19.2, date_to is used for version_id calculation, also employee_id is passed in context when we are coming from smart payslip button.
3 - Both compute_version_id (due to employee context) and compute_date_to triggers in hr_payslip and there is kind of race condition in here.
3.1 - Even though sometimes date_to is started to calculate before, when version_id is calculating the date_to is always False, the computation is not done yet.
3.2 - Since date_to is false, _get_version in hr_employee returns the first version of the employee, that's why in UI it is always the first version.
Bug solution:
1 - I passed the version_id from smart button to the payslip directly to prevent unwanted behavior.
task - 6014170This update fixes a technical error that prevented users from successfully printing payslips. The issue stemmed from incorrect data being passed to a key function, causing a traceback. The fix ensures payslips can be printed reliably, improving payroll processing.
Original PR description
Steps: - Install l10n_us_hr_payroll - Create an employee and contract - Create a leave allocation - Create a payslip and print it Issue: A datetime value was being passed to the generate_work_entries function, which caused a traceback. Fix: pass only the date to the generate_work_entries function.'
This update ensures that all event registration answers – including free-text responses – are correctly synchronized with the POS system. Previously, only selection-based answers were sent, leading to lost data. This fix corrects a technical issue that prevents accurate order processing during event ticket purchases.
Original PR description
## Steps to reproduce: - Configure event registration with only free-text fields (no selection field). - Open the POS, add an event ticket product, and fill in the registration form. - Click Payment…
## Steps to reproduce: - Configure event registration with only free-text fields (no selection field). - Open the POS, add an event ticket product, and fill in the registration form. - Click Payment and validate the order. ## Issue: - Registration answers were only sent to the backend when at least one selection-type question was filled. - When no selection field was present, free-text answers were not synced at all. ## Reason: - The `registration_answer_ids` and `registration_answer_choice_ids` One2many fields on EventRegistration both point to the same `registration_id` Many2one field on EventRegistrationAnswer. https://github.com/odoo/odoo/blob/c738d049fe09101bd14dce0710c2659a4a6eca39/addons/event/models/event_registration.py#L83-L85 - This caused data loss during the POS model synchronization, as entries were overwritten in the `inverseMap`. https://github.com/odoo/odoo/blob/c738d049fe09101bd14dce0710c2659a4a6eca39/addons/point_of_sale/static/src/app/models/related_models/model_defs.js#L59-L75 ## Fix: - Send all registration answers (free-text and selection-based) exclusively via `registration_answer_choice_ids`. task-5438565 Forward-Port-Of: odoo/odoo#252932 Forward-Port-Of: odoo/odoo#242465
This update resolves a technical error that occurred when processing refunds in the Spanish Point of Sale (POS) module. Specifically, a 'singleton error' was triggered due to incorrect data being passed during refund operations. The fix ensures the correct order ID is used, preventing the error and ensuring refunds process smoothly.
Original PR description
Step to reproduce: - install l10n_es_pos - create a pos, open its setting and set its `Simplified Invoice` with a journal - start pos, create a order and refund it Observation: - we receive a singleton error for account.move Cause: - when calling `get_invoice_name` method, we pass `order_server_ids` which contains order and refund order id, hence two ids are passed Fix: - instead of using `order_server_ids` we use 'order.id' i.e. current order opw-5870707 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251755 Forward-Port-Of: odoo/odoo#247986
This update optimizes the process of installing demo data in Odoo. It prevents unnecessary API calls and email notifications during this installation, resulting in faster and more efficient setup. This change improves the overall user experience and reduces server load.
Original PR description
Followup on https://github.com/odoo/odoo/pull/25086 to avoid making api calls, sending emails when installing demo data on an existing database Forward-Port-Of: odoo/odoo#252912
This update resolves a minor display issue in the account reports where the green comparison color was not consistently appearing. The fix corrects a conversion error introduced after the Dictalypse merge, ensuring the correct color is now displayed for comparison data.
Original PR description
With Dictalypse merged, there is a small mistake converting mode <=> comparison_mode since column_percent_comparison_data is now technically a column. The fix is to use comparison_mode instead of mode in the js view.
This update prevents a crash when multiple employees are selected and the 'End of Collaboration' action is initiated. The action was incorrectly designed to work with list views, leading to an error. Now, the action is only available when working with a single employee record in the form view.
Original PR description
## Steps to reproduce: - Go to Employees list view - Select multiple employees - Action menu > "End of Collaboration" - ValueError is raised: "Expected singleton: hr.employee(...)" ## Reason: - The server action `action_hr_employee_departure` had no explicit `binding_view_types`, so it defaulted to `list,form`. - When triggered from the list view with multiple records selected, it called `action_new_departure()` which enforces `ensure_one()`, causing a crash. - Multiple departures are no longer supported https://github.com/odoo/odoo/pull/245519/changes/774853c1e13a556edd61eea7f4bce65e8b7fc163 ## Fix: - Action is only surfaced in the form view, where the recordset is always a singleton. Task-3505331
This update corrects a technical issue where unused database records related to HR work entries were not being properly removed. The fix ensures the database remains clean and efficient, preventing potential performance impacts. This change is considered low impact.
Original PR description
The records `hr_work_entry.access_hr_work_entry_officer` and `hr_work_entry.access_hr_work_entry_system` no longer exist. They have been removed by https://github.com/odoo/odoo/pull/244436. runbot_build_error-240728
This update resolves an error that occurred when users attempted to generate lots without a defined sequence. The fix ensures the system handles cases where a product's lot sequence is not yet created, preventing a critical error and allowing lot generation to proceed smoothly. This improves the reliability of inventory management.
Original PR description
Currently, an error occurs when a user tries to generate lots while providing a lot number. **Steps to replicate:** - Install purchase (without demo). - Create a product `test`. - Install stock and…
Currently, an error occurs when a user tries to generate lots while providing a lot number.
**Steps to replicate:**
- Install purchase (without demo).
- Create a product `test`.
- Install stock and turn on `Lots and Serial Numbers`
- Open the product `test` and turn on `Track Inventory` `by Lots`.
- Open Receipts > add the product `test`> give demand as 3 > and go to its form view using view button.
- Click `Generate Lots` > type `lot1` in `First lot Number` > Generate > Error-1
- Click `Generate Lots` > type 0 in Quantity received > Generate > Error-2.
**Error-1:**
```
File '/home/odoo/odoo18/community/addons/stock/models/stock_move.py', line 1026, in action_generate_lot_line_vals
if (first_lot and first_lot == product.lot_sequence_id.get_next_char(first_number)):
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File '/home/odoo/odoo18/community/odoo/addons/base/models/ir_sequence.py', line 237, in get_next_char
interpolated_prefix, interpolated_suffix = self._get_prefix_suffix()
^^^^^^^^^^^^^^^^^^^^^^^^^
File '/home/odoo/odoo18/community/odoo/addons/base/models/ir_sequence.py', line 227, in _get_prefix_suffix
self.ensure_one()
File '/home/odoo/odoo18/community/odoo/orm/models.py', line 5640, in ensure_one
raise ValueError('Expected singleton: %s' % self)
ValueError: Expected singleton: ir.sequence()
```
**Error-2:**
```
File '/home/odoo/odoo18/community/addons/stock/models/stock_move.py', line 1025, in action_generate_lot_line_vals
first_number = product.lot_sequence_id.number_next_actual - product.lot_sequence_id.number_increment
^^^^^^^
UnboundLocalError: cannot access local variable 'product' where it is not associated with a value
```
---
**Cause:**
- Both errors originated through a recent [PR].
**Error-1 (Expected singleton: ir.sequence()):**
- As the product was already created before Inventory was installed, the `lot_sequence_id` was empty. (Note:`lot_sequence_id` field has a default value , but default value
assignment triggers only during the record creation, any records created
before stock is installed will not be assigned any value for
`lot_sequence_id`.)
- As no `lot_sequence_id` is assigned to `test` product the line [1] calls `get_next_char()` on an empty recordset which further calls `_get_prefix_suffix()` [2] and raises singletonerror from [here].
**Error-2 (UnboundLocalError: cannot access local variable 'product'):**
- As the `Received Quantity` was given 0, the `count` argument is received as 0 and as a result the `lot_qties` [3] and `lot_names` [4] are received as empty lists.
- This causes their [zip] to be empty list too and the loop never runs, so assignment to [product] variable never happens and causes the error to occur from here [5].
---
**Solution:**
**Error-1:**
- Now we perform write on `product.lot_sequence_id` only if it exists, otherwise we skip it.
**Error-2:**
- Moved the static assignment of variable `product` and `location_dest_id` outside the loop, this will also prevent the browse being called multiple times for browsing the same record.
[PR]: https://github.com/odoo/odoo/pull/240368
[1]: https://github.com/odoo/odoo/blob/7ab52c1675b9764d11454c7b5216064bec4628f8/addons/stock/models/stock_move.py#L1026
[2]: https://github.com/odoo/odoo/blob/7ab52c1675b9764d11454c7b5216064bec4628f8/odoo/addons/base/models/ir_sequence.py#L237
[here]: https://github.com/odoo/odoo/blob/7ab52c1675b9764d11454c7b5216064bec4628f8/odoo/addons/base/models/ir_sequence.py#L227
[3]: https://github.com/odoo/odoo/blob/7ab52c1675b9764d11454c7b5216064bec4628f8/addons/stock/models/stock_move.py#L989
[4]: https://github.com/odoo/odoo/blob/7ab52c1675b9764d11454c7b5216064bec4628f8/addons/stock/models/stock_move.py#L994
[zip]: https://github.com/odoo/odoo/blob/7ab52c1675b9764d11454c7b5216064bec4628f8/addons/stock/models/stock_move.py#L1000
[product]: https://github.com/odoo/odoo/blob/7ab52c1675b9764d11454c7b5216064bec4628f8/addons/stock/models/stock_move.py#L1004
[5]: https://github.com/odoo/odoo/blob/7ab52c1675b9764d11454c7b5216064bec4628f8/addons/stock/models/stock_move.py#L1025
sentry-7254849206,7265844194
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#248846This update resolves an issue where payments weren't automatically matched to invoices when 'Outstanding Receipts' accounts were configured in the bank journal. The fix allows for amount matching, ensuring payments are correctly reconciled with invoices, even with this account setting in place. This improves the accuracy of financial reporting.
Original PR description
Steps to reproduce - Have a Bank journal with Outstanding Receipts accounts set - Create and confirm an invoice with a payment reference - Create the payment - Create a bank transaction with: - Label: any label - Partner: invoice partner - Amount: invoice full amount Issue: Transaction won't be matched automatically Analysis: Transaction will be automatically matched if the outstanding receipts account is not set. It occurs because in case it is set, the sytem will only try to match the communication pattern against the journal item of the payment, without trying amount matching Note: another solution could be to relax the communication matching. In the user case the invoice payment reference is something like `TEST-12345` and the payment communication `AAAAAAAAAAA /BBBBBBBBBBB TEST 12345` opw-5872387 Forward-Port-Of: odoo/enterprise#109992 Forward-Port-Of: odoo/enterprise#108564
This update resolves a bug where the barcode scanning app incorrectly identified products when using barcodes that include product prices (starting with '23'). The fix adds logic to handle these barcodes, mirroring the functionality in the Point of Sale app, ensuring accurate product recognition.
Original PR description
Issue ----- Barcode app doesn't match products when using price-embedded barcodes. Steps to reproduce ----- - Use default nomenclature (so price embedded barcodes are 23...) - Create a product with barcode 2355555000004 - Go to barcode and scan 2355555009502 > The product isn't recognised Cause ----- There is no logic in place to handle such barcodes, but it can be added to mimic how it works in POS. https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/point_of_sale/static/src/app/screens/product_screen/product_screen.js#L212 ----- Ticket: opw-5901412 Forward-Port-Of: odoo/enterprise#110034 Forward-Port-Of: odoo/enterprise#109627
This update resolves a technical issue that prevented users from exporting data from the CRM forecast reports via the Kanban view. The problem occurred when the system processed empty month columns, leading to a division-by-zero error. This fix ensures data can now be reliably exported without errors.
Original PR description
Steps to reproduce: 1- Install CRM 2- Go to [CRM -> Reporting -> Forecast] 3- Export the data from Kanban view Description of issue: Traceback: ZeroDivisionError Expected behavior: Should export into excel sheet without error Why this happens: When exporting from a Kanban view, all month columns are processed even if they contain no records. In these cases: 1. `self.data` is empty, causing the logic to skip the if condition 2. Since `self.count` is 0, the final division fails with a ZeroDivisionError. opw-5962440 Forward-Port-Of: odoo/odoo#252262
A technical issue prevented the generation of customer statement reports. This fix ensures the necessary data is always provided to the report generation process, resolving an error that caused the preview and PDF generation to fail. This improves the reliability of a key reporting feature.
Original PR description
**Steps to reproduce:** * Install the **l10n_my_reports** module. * Go to `Accounting > Reporting > Partner Ledger`. * Change report to `Customer Statement`. * Add data in the report and click Send. * In the email template, set the `dynamic reports` as `statement of accounts` under the options tab. * Click Preview. **Observed behavior:** * Error: `TypeError: Domain() invalid argument type for domain: None` * Email preview fails and PDF cannot be generated. **Cause:** * The `statement_account_document` template uses `filtered_domain(domain)` but the domain variable was not being passed to the template context by the `_get_report_values` method, resulting in None being passed to `filtered_domain()`. **Fix:** * Ensure domain is always present in the report context, defaulting to an empty list when not provided. * Added safe handling for missing data and context parameters. opw-5880385 Forward-Port-Of: odoo/enterprise#107400
This update fixes a potential error in the Account PEPPOL module that could cause sync failures when a PEPPOL user isn't configured. The change simply skips the email proxy sync process in these situations, ensuring smoother and more reliable operation. This improves the overall stability of the PEPPOL integration.
Original PR description
**[FIX] account_peppol: skip contact email proxy sync when no peppol user exists.** Before this fix the sync would fail in certain scenarios when there is no proxy user preset in the database. The fix is to simply skip the proxy call if no user is present. opw-5980696 Forward-Port-Of: odoo/odoo#251719
This update fixes a display issue in the SEPA payment wizard, ensuring the warning message accurately reflects the number of payments being processed (originally showing 4 when only the first installment was being paid). Additionally, a visual bug where the 'group payment' button was incorrectly displayed has been resolved. This ensures accurate payment tracking and a better user experience.
Original PR description
[FIX] account: right number of payments skipped in send wizard Steps to reproduce: - install modules account_sepa_direct_debit, account_iso20022 - create 2 vendor bills with payment terms so that there are 2 installments per bill, and post them - from the list view, select both bills and click pay - select SEPA as a payment method, a warning message is displayed mentionning 4 payments We want the warning to display a number of 2 payments because we're paying only the first installment of each bill This commit also fixes the visibility of the "group payment" button: when two bills from different suppliers were selected with one having installments, the button was visible task-5917803 Forward-Port-Of: odoo/odoo#252870 Forward-Port-Of: odoo/odoo#247830
This update fixes an issue where the SEPA payment wizard incorrectly displayed the number of payments being skipped. The change ensures the warning message accurately reflects that only the first installment of each bill is being paid. Additionally, a visual bug related to the 'group payment' button has been resolved.
Original PR description
[FIX] account_iso20022: right number of payments skipped in send wizard adding tests to the community commit Steps to reproduce: - install modules account_sepa_direct_debit, account_iso20022 - create 2 vendor bills with payment terms so that there are 2 installments per bill, and post them - from the list view, select both bills and click pay - select SEPA as a payment method, a warning message is displayed mentionning 4 payments We want the warning to display a number of 2 payments because we're paying only the first installment of each bill This commit also fixes the visibility of the "group payment" button: when two bills from different suppliers were selected with one having installments, the button was visible task-5917803 Forward-Port-Of: odoo/enterprise#110020 Forward-Port-Of: odoo/enterprise#106894
This update fixes an issue where average daily and weekly hours weren't calculated correctly when using the 'Define Amount of Hours per Day' option in employee schedules. The fix ensures that hours are accurately computed based on duration when this option is selected, leading to more reliable time tracking data.
Original PR description
## Short functional explanation of the error When editing attendances of a schedule for which we checked the box `Define Amount of Hours per Day`, the resulting average hours per day and hours per…
## Short functional explanation of the error When editing attendances of a schedule for which we checked the box `Define Amount of Hours per Day`, the resulting average hours per day and hours per week fields aren't computed correctly. ## Reproduction Steps 1. Go to Employee > configuration > Working Schedules. 2. Create a working schedule. Check the box Define Amount of Hours per day and in the Working Hours tab, remove all intendances. 3. Add a line for Monday, set the day period to Full Day and the duration in hours to 4. 4. Repeat the operation for tuesday and wednesday. ### Expected behavior As we have 3 days during which we work 4 hours, the average hours per day should be 4, and the total hours per week should be 12. ### Unexpected behavior The average hours per day and hours per week don't show the correct numbers. ## Origin of the issue We compute the hours per week with this method: https://github.com/odoo/odoo/blob/ae9fd7cc7d434d4b222c81aa58515c57d7426b65/addons/resource/models/resource_calendar.py#L690-L696 However, when we check the box `Define Amount of Hours per Day`, we don't set the attendances starting and ending hours. Instead, we work with duration hours. Therefore, when the box is checked, we have to compute the weekly hours with the field `duration_hours`, and not `hour_from` / `hour_to`. __ opw-5885571 Forward-Port-Of: odoo/odoo#248627
This update resolves an issue preventing remote calls to certain class methods within Odoo. Specifically, methods defined as `@classmethod` or `@staticmethod` were incorrectly accessible. This change enforces a stricter policy, ensuring only standard methods can be called remotely, improving overall system security and stability.
Original PR description
Access /doc, see that `is_transient` is listed, call it via JSON-2. Error 422 "Unprocessable Entity": too many positional arguments.
The `is_transient` method is defined as follow:
```py
@classmethod
def is_transient(cls) -> bool:
""" Return whether the model is transient.
See :class:`TransientModel`.
"""
return cls._transient
```
It is a `@classmethod` and take no argument. Only regular methods can be called remotely. The `@classmethod` and `@staticmethod` (actually, all methods that are defined on the class, and not on the instance) are now considered private.
Reported-by: Florent Xicluna <florent.xicluna@camptocamp.com>
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#253066
Forward-Port-Of: odoo/odoo#252739This update corrects a calculation error in the HRA (House Rent Allowance) rules for Indian employees. The change ensures that HRA percentages are accurately applied, aligning with standard India payroll practices. This improves the consistency and reliability of employee compensation calculations.
Original PR description
… fields - compute HRAMN from categories['BASIC'] with result_rate = l10n_in_hra_percentage * 100 - add python condition to skip the rule when HRA percentage is zero - keeps ind_emp behavior consistent with regular India payroll rules task-5964270 Forward-Port-Of: odoo/enterprise#108507
This update fixes an error in how outstanding amounts are calculated when a down payment is reversed with a credit note. Previously, the system incorrectly produced negative amounts, leading to incorrect settlement calculations. Now, the system accurately reflects the remaining balance, ensuring proper financial reporting.
Original PR description
When having a down payment that is reversed by a credit note, the amount unpaid is wrongly computed. This is because we take the sum of invoice lines price total, regardless they come from invoice or credit note. Therefore we end up with negative value. Steps: - Have a SO for 500 - Make a downpayment for 300, confirm - Make a credit note for the downpayment invoice, confirm -> SO's amount unpaid is -100, it should be 500. If you now settle the SO, the amount unpaid will be -300 instead of 0. opw-5175562 Forward-Port-Of: odoo/odoo#253135 Forward-Port-Of: odoo/odoo#233248
This update corrects a validation error that occurred when sending invoices to Peppol. The system previously used an outdated UoM conversion ('QT') that is no longer compliant with UN/ECE standards. This fix ensures invoices meet current regulatory requirements for international exchange.
Original PR description
Currently, the Odoo UoM 'qt (US)' is converted to 'QT', which is not valid anymore. Based on investigation, this was originally set to QT following this link: https://unece.org/fileadmin/DAM/cefact/recommendations/rec20/rec20_rev3_Annex2e.pdf But this document seems dated from 2005. Step to reproduce: - Create an invoice with a line with 'qt (US)' as UoM - Try to send the invoice to Peppol - You will get a validation error: "[BR-CL-23]-Unit code MUST be coded according to the UN/ECE Recommendation 20 with Rec 21" Also removed the link to unece.org since the link is no longer valid. opw-5961476 Forward-Port-Of: odoo/odoo#252803 Forward-Port-Of: odoo/odoo#252174
This update resolves a technical issue within the Odoo Enterprise payroll module (l10n_be_hr_payroll) that was causing errors. The fix corrects a mistake in how the system processed data, preventing a system failure and ensuring accurate payroll calculations. This ensures the payroll system continues to function correctly.
Original PR description
Use the correct var instead of self in the loop.
This solve the raise ValueError("Expected singleton: %s" % self) raised by the orm.This update fixes an issue where customers could set subscription start dates to 'False', leading to incorrect invoicing. The change prevents users from removing the start date, ensuring subscriptions are correctly billed moving forward. This maintains accurate subscription tracking and billing.
Original PR description
**Issue** Some customers were removing the `start_date` of subscriptions, leading to the subscription being considered free on the next invoicing. While there are legitimate use cases to edit the `start_date` of a running subscription, it should probably not be removed. opw-5325303 Forward-Port-Of: odoo/enterprise#104925
This update resolves an issue where early payment discounts weren't correctly processed when invoices were generated in the Factur-X format. The change adds the necessary handling for Early Payment Discounts (EPD) within this format, ensuring accurate invoice generation and compliance. This improves the accuracy of financial reporting.
Original PR description
Added the handling of early payment discount in the factur-x format. opw-5265981 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252411 Forward-Port-Of: odoo/odoo#244659
This update fixes an issue where the available quantity for rental products was incorrectly displayed on the ecommerce page when 'continue selling' was enabled. The fix ensures that the displayed quantity accurately reflects the available rental units based on the selected renting period, improving the customer experience. This resolves a discrepancy in how rental stock availability is calculated.
Original PR description
**Issue**: The displayed available quantity on the ecommerce product page is incorrect for rental products when "continue selling" is enabled. **Steps to reproduce**: - Create a rental product…
**Issue**: The displayed available quantity on the ecommerce product page is incorrect for rental products when "continue selling" is enabled. **Steps to reproduce**: - Create a rental product tracked in stock with a quantity of 5 - Enable "continue selling" and "show available quantity below 10" - Go to the ecommerce page of this product - Rent 3 units for a given period, confirm and pay - Return to the ecommerce product page -> Whatever the selected renting period, the displayed quantity is always 2 **Cause**: The website displays `free_qty`: https://github.com/odoo/enterprise/blob/41c729e22c5fd1abb690f8335e933f793be0b319/website_sale_stock_renting/static/src/xml/website_sale_stock_renting_product_availability.xml#L15 `free_qty` is computed in: https://github.com/odoo-dev/odoo/blob/0935829ddaecd7b2b6eec9157f8f790b546d06ff/addons/website_sale_stock/models/product_template.py#L36 which leads to: https://github.com/odoo/enterprise/blob/41c729e22c5fd1abb690f8335e933f793be0b319/website_sale_stock_renting/models/website.py#L10 and ultimately relies on: https://github.com/odoo/odoo/blob/37bf1703c7478a3010b71cd60bbb43b3295a605b/addons/stock/models/product.py#L213 This computation does not take the selected renting period into account. There is a period-aware computation here: https://github.com/odoo/enterprise/blob/41c729e22c5fd1abb690f8335e933f793be0b319/website_sale_stock_renting/models/website.py#L15C17-L21C1 but it is only triggered when `product.allow_out_of_stock_order` is False (i.e. when "continue selling" is disabled). opw-[5354163](https://www.odoo.com/web#id=5354163&view_type=form&model=project.task) Forward-Port-Of: odoo/enterprise#105159 Forward-Port-Of: odoo/enterprise#103333
This update fixes an issue where the Instagram API would return errors when trying to retrieve poll information before a post was fully published. The change now checks the post's status first and only requests the poll ID when the post is confirmed as published, preventing errors and ensuring smoother operation. This improves the reliability of Instagram polls within the system.
Original PR description
Follow-up to 06256aa02cb92378933edd638259dd725a2d04c1 The Instagram API returns an error if the `ig_id` field is requested while the container is still processing. This commit splits the container status check into two steps: 1. Poll for `status_code` only to determine the current state. 2. If the status is `PUBLISHED`, perform a second request to fetch the `ig_id`. Updated the test mocks to simulate this restriction, ensuring that requesting `ig_id` on a non-published container results in a 400 error to prevent future regressions. opw-5081325 Forward-Port-Of: odoo/enterprise#110094
This update resolves an issue where the website blog would display an error when users tried to access URLs with invalid tag information. The fix ensures that the system correctly handles cases where tag IDs are missing, preventing the error and maintaining a stable browsing experience for website visitors. This change improves the overall reliability of the website blog feature.
Original PR description
Steps to reproduce: - Install `website_blog` module(with demo data) - Change URL (eg: /blog/tag/hotels) Traceback: `AssertionError: Invalid falsy real id` We are encountering this error because [active_tag_ids] contains `[None]`, and falsy IDs are no longer allowed in `browse()`. [active_tag_ids]: https://github.com/odoo/odoo/blob/4e4d1dba32ef45567eda004fc1a3584591508720/addons/website_blog/controllers/main.py#L83 sentry-7289765426 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250647
This update fixes a minor typo in the name of a work entry type used in the Belgian version of Odoo. The change ensures accurate reporting and data consistency for overtime hours related to social security contributions. This update does not impact core functionality.
Original PR description
Version: saas-19.1 Fix typo in belgian work entry type name: - from "Overtime Hours not suject to social security contribution" to "Overtime Hours not subject to social security contribution" Task-5946323 Forward-Port-Of: odoo/odoo#249209
This update resolves an issue where purchase events weren't sending the correct data to Google Analytics. The fix converts a JSON string received from the website into a proper object, ensuring all purchase details (like transaction ID and value) are accurately tracked. This improves the accuracy of our website analytics.
Original PR description
## Description The `Tracking` interaction's `setup()` method reads order tracking info from the HTML `data-order-tracking-info` attribute and passes it directly to `_trackGa()` → `gtag()`. Since the…
## Description The `Tracking` interaction's `setup()` method reads order tracking info from the HTML `data-order-tracking-info` attribute and passes it directly to `_trackGa()` → `gtag()`. Since the DOM `dataset` API always returns strings, `gtag()` receives a JSON string instead of an object, causing GA4 to silently drop all purchase event parameters (`transaction_id`, `value`, `items`, etc.). Compare with `onAddToCart()` in the same file, which receives its data via `CustomEvent.detail` (already a JS object) and works correctly. **Impacted versions:** - 19.0 **Steps to reproduce:** 1. Configure a Google Analytics key in Website > Settings 2. Add a product to cart and complete checkout 3. On `/shop/confirmation`, inspect the dataLayer or GA4 debug view **Current behavior:** - `add_to_cart` event fires with correct ecommerce parameters (object) - `purchase` event fires with a JSON **string** instead of an object — GA4 silently drops the parameters **Expected behavior:** - `purchase` event fires with a parsed object containing `transaction_id`, `value`, `currency`, `tax`, `items` **Fix:** Add `JSON.parse()` to convert the data attribute string back to an object before passing it to `gtag()`. --- I hereby confirm I have signed the Odoo CLA (included in this PR as `doc/cla/corporate/comma.md`). Forward-Port-Of: odoo/odoo#253074
This update fixes a persistent issue where temporary files were left behind during browser testing. By using a more robust cleanup system with ExitStack, the code now ensures all temporary files are removed regardless of test success, improving test reliability and reducing potential data inconsistencies. This change enhances the stability of our automated tests.
Original PR description
Trying to find out why I kept having a bunch of leftover `tmpsomethingsomethign_chrome_odoo` leftovers I realised #203412 had a bit of an error in the location of the `atexit.callback(browser.stop)`:…
Trying to find out why I kept having a bunch of leftover `tmpsomethingsomethign_chrome_odoo` leftovers I realised #203412 had a bit of an error in the location of the `atexit.callback(browser.stop)`: the temporary directory for the user data dir is created as soon as the browser is instantiated, but the cleanup is only recorded after a successful `navigate_to`, so if that (or a previous step e.g. authentication) fails then the tempdir is never cleaned up. Rather than just move the call up the body and re-introduce conditionals to `stop` to handle more partial initializations though, use the magic of ~~buying two of them~~ `ExitStack` to record cleanup requirements dynamically as the `ChromeBrowser` initialises. This initially used a bunch of `ExitStack.callback` calls with ad-hoc cleanup, but turns out most of these cases are better as CMs: - replace `mkdtemp` / `rmtree` by `TemporaryDirectory`, which Just Works as a CM - add context-manager methods to the screencaster classes (also remove `stop` which is redundant with `__exit__`) so they Just Work as CMs - convert `_chrome_start` and `_open_websocket` to `@contextmanager`... for obvious reasons This makes the relation between setup and cleanup clearer, as well as more self-contained in case we want to move stuff to a submodule eventually. It also ensures cleanups run in the correct order, and avoids having to deal with partial initializations. Keep `ChromeBrowser.stop` because it seems unnecessary to edit those out for now, but have it just `close` the exitstack (which runs all the registered cleanups). NOTE: it might make sense for `browser_js` to just use `ChromeBrowser.cleanup` instead of having its own exitstack, not entirely sure... Alternatively it might make sense for ChromeBrowser to *take* a CM as parameter... and / or for ChromeBrowser to *be* a CM? Forward-Port-Of: odoo/odoo#253035
This update fixes a technical issue causing excessive, unwanted warnings within Odoo. The problem stemmed from an outdated version of Werkzeug being used, which incorrectly handled warning messages. This has been resolved by updating to a version with the necessary fixes, preventing duplicate warnings and improving system stability.
Original PR description
Every manipulation of the warnings list flushes the warnings registry, which prevents `warnings.warn` from deduplicating `default`, `module`, and `once` actions, instead they all behave as if `always`. Because werkzeug.urls is used *a lot* in odoo, this causes warnings to be emitted continuously even if that's not intentional, something which is already an issue due to workers (every new worker has an empty warnings registry triggering duplicate warnings). Upstream fixed this issue in pallets/werkzeug#2692 which was merged in 2.3.4, but apparently we vendored 2.3.0 which didn't have these fixes. Forward-Port-Of: odoo/odoo#252427 Forward-Port-Of: odoo/odoo#252193
This update ensures invoices are generated correctly by only using bank accounts that are authorized for outgoing payments. Previously, errors could occur if an invalid bank account was selected. Now, the system prioritizes customer and payment journal banks, ensuring smoother transactions and preventing potential payment failures.
Original PR description
Before this commit: --- - Invoice generation could fail when the selected partner or company bank did not allow outgoing payments. - The first available bank account was used without checking whether it was valid for out payments. After this commit: --- - Select only bank accounts that allow outgoing payments. - Prioritize customer banks for refunds, then payment journal banks, and finally company banks as fallback. - Prevent errors caused by untrusted or unsupported bank accounts. task-5954530 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253158 Forward-Port-Of: odoo/odoo#250062
This update resolves an issue in the Nemhandel integration for Denmark (DK) by adding a required attribute to the XML format. Specifically, the 'schemeID' was missing, which is essential for correctly identifying the buyer according to OIOUBL 2.1 standards. This ensures accurate data exchange with Danish tax authorities.
Original PR description
Nemhandel follows the OIOUBL 2.1 XML format. To specify the Buyer identifier, we use the <cac:PartyIdentification> node. But we are missing the `schemeID` attribute, which should be for DK "DK:CVR". This commit adds this attribute. opw-5232123 Forward-Port-Of: odoo/odoo#253132 Forward-Port-Of: odoo/odoo#250942
This update fixes an issue where the Website Studio XML editor incorrectly displayed translations for all websites, regardless of the current website being used. The change ensures that translations are only applied when editing views within the Website Studio editor, improving the user experience and preventing incorrect translation display.
Original PR description
Problem: When opening the Studio XML editor when Website is installed, the translation terms corresponding to the Default Language of the first website in the database are used. This behavior should only be applied to the HTML/CSS Editor in Website. Purpose: Modify Website's override of get_related_views to only return translated views when called with a specific website in context. This is done here by adding a context flag, as to not interfere with customizations made in stable versions. This will be changed for master. Steps to Reproduce in Runbot: 1. Activate a non-English (US) language. 2. Add this language to the Website with the lowest ID in the database, then set it to the Default Language of the Website. 3. Enter Studio and navigate to a view that has translation terms in its view (ex. Invoice PDF Report), then open the XML editor. opw-5136124 Forward-Port-Of: odoo/odoo#252063 Forward-Port-Of: odoo/odoo#237000
This update ensures that Website Studio's translation terms are correctly applied only to views within the Website module, resolving an issue where the default website's language was being used. This change improves the accuracy of translations within the Studio editor, providing a more reliable experience for users working with Website-related views.
Original PR description
Problem: When opening the Studio XML editor when Website is installed, the translation terms corresponding to the Default Language of the first website in the database are used. This behavior should only be applied to the HTML/CSS Editor in Website. Purpose: Modify Website's override of get_related_views to only return translated views when called with a specific website in context. Steps to Reproduce in Runbot: 1. Activate a non-English (US) language. 2. Add this language to the Website with the lowest ID in the database, then set it to the Default Language of the Website. 3. Enter Studio and navigate to a view that has translation terms in its view (ex. Invoice PDF Report), then open the XML editor. opw-5136124 Forward-Port-Of: odoo/enterprise#109572 Forward-Port-Of: odoo/enterprise#107459
This update fixes an issue where cancelled stock moves were incorrectly impacting the calculation of kit costs in sales orders. The change ensures that only completed stock moves are used when determining kit component values, resulting in more accurate sales order pricing. This improves the reliability of sales reporting.
Original PR description
Currently cancelled moves are also being used when getting the value. This is already done in the main method: https://github.com/odoo/odoo/blob/049321aa5e0d4271050b406477bac5fb788b410b/addons/stock_account/models/account_move_line.py#L67 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253028
This update corrects tax reporting templates for Belgium, Netherlands, Luxembourg, and France, ensuring accurate UBL/CII tax category and exemption reason codes are used. Specifically, the BE tax template now correctly identifies tax codes for all taxes, resolving previous inconsistencies and improving compliance with international tax regulations.
Original PR description
Before this commit : NL,FR,LU tax templates did not define the UBL/CII tax category and exemption reason codes. In BE tax template, all cocontracting taxes had "AE" tax code and "VATEX-EU-AE" tax exemption reason code, even for non-0% cocontracting taxes. Some other taxes didn't have the correct codes. After this commit : All relevant NL,FR and LU tax templates now define their UBL/CII tax category and exemption reason codes. Specific reason codes are assigned where applicable. In BE tax template, taxes are now corrected, all taxes have their relevant tax codes. task-4976471 --- I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr) Forward-Port-Of: odoo/odoo#251262 Forward-Port-Of: odoo/odoo#250013
This update resolves a UI issue that occurred when changing wage intervals in the employee payroll settings. The problem stemmed from extra text being inserted into the employee form, causing errors. This fix removes the problematic text, ensuring correct wage interval handling.
Original PR description
Bug production steps: First, I created a new db with saas-19.1 db from runbot, from payroll->employee->Payroll tab in form view, when you change wage interval to another thing than 'month' error occurs Bug cause: There is another text like /2 months, /2 weeks are inserted from hr_employee_views in the hr_contract_salary_payroll to the XML of the employee form view. Bug solution: Removing the corresponding XML insertions. task - 5469378 Forward-Port-Of: odoo/enterprise#104116
This update ensures that our UY e-invoicing process can correctly validate invoices by granting necessary permissions to access company-specific data. Previously, the system would fail if the user lacked specific group access, leading to validation errors. This change resolves that issue and improves the reliability of the UY e-invoicing feature.
Original PR description
This pull request makes a small update to the `_ucfe_inbox` method in `l10n_uy_edi_document.py` to ensure that company-specific fields are always accessed with the appropriate permissions. This is achieved by using the `sudo()` method when retrieving the `l10n_uy_edi_ucfe_commerce_code` and `l10n_uy_edi_ucfe_terminal_code` fields from the `company` record. * Ensured that `l10n_uy_edi_ucfe_commerce_code` and `l10n_uy_edi_ucfe_terminal_code` fields are accessed with elevated permissions by calling `company.sudo()` in the `_ucfe_inbox` method (`l10n_uy_edi_document.py`). Without this fix, if the user doesn't belong to group "base system", it won't be able to validate CFEs, receiving the following message: <img width="1272" height="400" alt="image" src="https://github.com/user-attachments/assets/ec4223fb-5b96-4a3e-babf-2f6a35ecd123" /> Forward-Port-Of: odoo/enterprise#105918
This update fixes a bug where invoices were being created for timesheets that had already been billed, leading to inaccurate financial records. The change prevents the system from generating new invoices for timesheets that have been fully invoiced, ensuring correct billing and reporting. This resolves a critical issue impacting invoice accuracy.
Original PR description
__ ## Short functional explanation of the error When we create an invoice for a quotation that holds a timesheet product and recorded timesheets for last month. In the wizard, we set the timesheet…
__ ## Short functional explanation of the error When we create an invoice for a quotation that holds a timesheet product and recorded timesheets for last month. In the wizard, we set the timesheet period from the first to the last day of last month. Then, we set the `Invoicing Switch Threshold` to the day of last month. We record another hour for the timesheet, for this product, for today. When we select last month as timesheet period when creating a new invoice, the 2 hours that have already been invoiced are reinvoiced. Moreover, once we confirm this second invoice, it is possible to create again and again invoices for these already invoiced timesheets, without changing the Invoicing Switch Threshold parameter. ## Reproduction Steps 1. Create a quotation. Add as a line a timesheet product. Set the quantity to 2. Validate and click on the smart button Recorded. 2. Record 2 hours with a random date for last month. 3. Create an invoice. In the wizard, set the timesheet period to the first -> the last day of last month. Confirm, and on the invoice form, set the invoice date to last month (after the day on which you recorded the timesheet hours) and confirm. 4. Click on configuration > settings. Search for Invoicing Switch Threshold, and set the date to the last day of last month. 5. Go back to the invoice you created. It should have the ribbon `Ìnvoicing App Legacy`. 6. Go back to the sales order. Click on the smart button Recorded and add one more hour to the timesheets, but this time in February. 7. Create an invoice. On the wizard, set the timesheet period to the first -> last day of last month. Click confirm. ### Expected behavior The system shouldn't let us create an invoice, as we have nothing to invoice, as all the timesheets have already been invoiced. ### Unexpected behavior An invoice is created with 2 hours. It doesn't take into account the hours added in February (normal) but reinvoices the timesheets that have already been invoiced (not normal). ## Origin of the issue When retrieving the quantities to invoice for the timesheets, we don't take into account the quantities already invoiced for the same timesheet. __ opw-5426434 Forward-Port-Of: odoo/odoo#250946
This update clarifies the message displayed when a live chat conversation ends, replacing ambiguous ellipses with a clear statement. This change improves the user experience by removing potential confusion and ensuring users understand the conversation has concluded. The update was part of a larger maintenance effort.
Original PR description
This commit updates the chatbot completion message from 'Conversation ended...' to 'Conversation has ended.' The previous version used ellipses, which typically suggest an incomplete thought. Since the message is meant to clearly indicate that the conversation has concluded, the ellipses were unnecessary and potentially confusing. Forward-Port-Of: odoo/odoo#253167 Forward-Port-Of: odoo/odoo#251166
This update fixes a visual inconsistency in the mega menu on mobile devices. Changing the navbar font style (like 'Arvo') caused the back arrow to display with an incorrect font. The fix ensures the back arrow uses the standard Odoo UI icons, maintaining a consistent and professional appearance.
Original PR description
Steps to reproduce: =================== 1. Go to webstie and add a mega menu 2. Change Navbar font (e.g. to "Arvo") 3. Switch to mobile view and open the mega menu -> the back arrow will have unexpected style. Cause: ====== The selector `.navbar .nav-link` applies the custom navbar font-family (e.g., "Arvo") to all `.nav-link` elements inside the navbar. The mega menu back button has classes `btn nav-link oi oi-chevron-left`, so it matches this selector. Since `.navbar .nav-link` has higher specificity than the base `.oi` class, the custom font overrides `font-family: 'odoo_ui_icons'`. Solution: ========= force the .oi font-family. opw-5949405 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251394
This update corrects a minor issue where the styling of popups wasn't always reflecting the most current state. The fix ensures that popup displays are consistently updated, preventing potential visual inconsistencies. This improves the overall user experience and reliability of the website.
Original PR description
The attribute change processor supposed to avoid changing the `display` property of the `style` attribute of the popup element when an history step is replayed (added in cce4527c85e3240ff50fa573b141bc5973a46c2e) was mistakenly using the old display value from the history instead of the current value of the target. This was usually not an issue because in the cases where those value differed, the popup was about to be revealed (or hidden) anyway to show the target at that history step. This commit keeps the value of the property `display` of the `style` attribute as it is currently on the target, instead of the value of what it should have been as registered by the history. task-5149984 Forward-Port-Of: odoo/odoo#253106
This commit addresses several improvements and bug fixes within the Field Service module, primarily focused on enhancing the reporting and usability for planning users. Key changes include accurate timesheet calculations, improved report visibility, and streamlined workflow adjustments to ensure data consistency and a better user experience.
Original PR description
This commit continues to review the new Field Service to make sure the features migrated from the old Field Service are still available and also improve a bit the flow to facilate the day to day of…
This commit continues to review the new Field Service to make sure the features migrated from the old Field Service are still available and also improve a bit the flow to facilate the day to day of planning users using Field Service feature. In detail, this commit will: - fix traceback and access rights on creation of worksheet - use generated timesheets of the intervention for the report. To do that a new one2many field called `intervention_timesheet_ids` is added in `planning.slot` model. And so instead of relying on 'timesheet_ids' of the slot, which are not necessarily linked to the intervention, we compute the effective hours based on the timesheets generated by the intervention, and use that field in the report and stat button. - change color of trash button in form view in gantt - make sure no planned shifts are not displayed - simplify kanban card when shift is not planned - some relabeling and change worksheet visibility condition in the report - hide resource_ids in calendar popover when empty - hide Field Service report if no customer report - compute is_absent field if shift is not completed - raises a user error when the user tries to reset the state of an intervention in draft if the state was in progress or completed - hides `Hide price on customer report` in settings of planning app if `Customer Report` feature is disabled - add space between worksheet and photos in the portal view and in Field Service report - compute quotations_count field in planning.slot only if the user has sales access - makes sure the context is reset before taking the display name of the customer set to set it to display name of the shift. Because before this commit, when the user creates a new shift and set a customer to the intervention, the display_name of the shift will contain the customer name but also his address which is not really expected. - reorder worksheets data/demo to have the one created in demo data first once the demo data are loaded - relabel email template in field service - order the tracking in planning.slot - reset SO when customer changes - show field service stat button in SO when SO is generated/linked to an intervention. - text white for conflicts tag in kanban otherwise the text is not correctly lisible in light mode. - fix worksheet visibility in portal/report - fix action_complete() and sale_line_id computation when no SO - review card_top of kanban card of planning slot - hide effective_hours and related fields from views/reports - remove group to prevent access errors in SO - hide partner_phone if no partner set on the shift - add photos in field service report - don't allow to add material on draft or published, we should only be able to add material when the intervention is in progress or completed task-5994280
This update streamlines the search functionality within the sales timesheet module. A previous extension to the 'Services & Materials' search view was removed, eliminating unnecessary options based on data that wasn't consistently used. This improves search performance and clarity for users.
Original PR description
This commit disables an unnecessary search view extension in `sale_timesheet` for the *Services & Materials* view. The extension was adding *group by* and *filter* options based on the fields `project_id`, `employee_id`, and `task_id` which are never set on Services analytic lines. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a minor issue in the Belgian payroll module (l10n_be_hr_payroll) by using the correct loop variable instead of 'self'. This ensures accurate calculations and reporting related to employee payroll processing, improving data reliability.
Original PR description
Use loop variable instead of `self`.
This update corrects a minor issue in the account reports module, ensuring that comparisons are displayed accurately. Following the recent Dictalypse merge, a change was made to how data is processed, and this fix ensures the green comparison indicator functions correctly. This improves the clarity and reliability of financial reporting.
Original PR description
With Dictalypse merged, there is a small mistake converting mode <=> comparison_mode since column_percent_comparison_data is now technically a column. The fix is to use comparison_mode instead of mode in the js view.