Daily updates from Odoo
Wednesday, June 3, 2026
125 changes
23 changes
Resolved issues and error corrections
This update fixes an issue where users couldn't reliably select formatted text within a table cell. The fix simplifies the selection process by directly verifying cell boundaries, ensuring consistent and accurate cell selection when applying formatting. This improves the overall usability of the table editor.
Original PR description
### Steps to reproduce: - create a table (e.g. /table) - type something in any cell and select that cell. - apply formatting through toolbar (bold, italic, etc.) - now select that single cell through…
### Steps to reproduce: - create a table (e.g. /table) - type something in any cell and select that cell. - apply formatting through toolbar (bold, italic, etc.) - now select that single cell through mouse. - observe that it is not selected ### Description of the issue/feature this PR addresses: - The single-cell selection logic relied on getTargetedNodes(), which collects descendants of the selection’s common ancestor. When selecting text inside inline formatting tag (e.g. `<i>`), the text node became the common ancestor, so the parent `<i>` tag was excluded from selectedNodes. As a result, check ensuring all cell elements were selected failed, preventing from being selected. ### Desired behavior after PR is merged: - Cell selection was simplified using areNodeContentsFullySelected(startTd) directly instead of manually matching targeted descendants. This relies on DOM Range to verify whether the cell boundaries are fully selected. task-6207941 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266208 Forward-Port-Of: odoo/odoo#263742
This update optimizes the styling of the Odoo Enterprise website's home menu for faster loading times. The changes eliminate inefficient CSS selectors used with hover and active states, replacing them with CSS variables for better performance. This results in a smoother user experience.
Original PR description
Avoid selectors after `:hover` and `:active`, as they can impact performance. CSS variables are now used instead. Replace hex color values with "0 0 0" RGB syntax to ensure compatibility with CSS variable usage. Forward-Port-Of: odoo/enterprise#119082
This update fixes a technical issue that prevented the system from correctly processing paychecks with negative amounts. The fix involved correcting references to negative net values and removing unnecessary code, ensuring accurate paycheck calculations. This resolves a potential error that could have impacted payroll accuracy.
Original PR description
Steps to produce: - create a previous payslip with negative amount - create a payslip for current month - click on the warning to apply negative amount - you get an error or a traceback because it's referencing an input which is removed from the system and migrated to other input Fix: - corrected the reference to negative net - removed content of the method `_generate_payslip` as it's not used and referencing removed inputs task-id: 6240163 Forward-Port-Of: odoo/enterprise#119010 Forward-Port-Of: odoo/enterprise#118144
This update resolves an issue where clicking on social media posts (Facebook, Instagram, YouTube) without comments would cause the system to crash. The fix ensures that the comments dialog opens correctly, regardless of whether the post has comments or not, improving the user experience within the Social Marketing feed.
Original PR description
*=social_youtube,social_instagram,social_facebook,social_twitter, social_linkedin **How to reproduce:** - Open the Social Marketing feed. - Click a Facebook, Instagram, or YouTube stream post with no comments. **Issue:** - A traceback is raised because the click handler tries to call `click()` on a missing comments element. - The comments dialog does not open. **Cause:** - The kanban record click handler forwards clicks to `.o_social_comments`. - For some media, the comments counter is not rendered when the post has zero comments. - See: https://github.com/odoo/enterprise/commit/0293d3e839825a4333882e831960050070b02ba6 **Fix:** - Make the shared handler detect when the comments element is missing. - Delegate that case to media-specific handlers so Facebook, Instagram, and YouTube can open their comments dialog directly. Task-6113089
This update removes redundant sudo permissions that were incorrectly added when calling the image generation tool. The change corrects a previous error and improves the system's efficiency and security posture. This ensures the system operates with the minimum necessary privileges.
Original PR description
The sudo used for calling the image generation tool isn't needed and shouldn't have been added here 99f76c1 in the first place. So, it is removed.
This update fixes an issue where timesheet forms weren't displaying the correct, specialized view when refreshing after opening from the grid. Now, the system correctly restores the timesheet-specific form view, ensuring users always see the relevant information when navigating back to a timesheet record.
Original PR description
…m view * Go to Timesheets > My Timesheets > switch to Grid view. * Hover over a cell with a timesheet entry and click the magnifier (search) icon. * The list opens; click a record to open its form view. * Observe the URL: `/odoo/timesheets/account.analytic.line/<id>`. * Refresh the page (F5). Before this commit, the generic form view was shown instead of the timesheet-specific form view. This occurred because, when reloading a page with a dynamic action and a resId, a generic view layout [false, "form"] was requested instead of the action-defined view. Now, the dynamic action is properly restored on refresh, ensuring the correct specific view is loaded for the form. opw-6133602 Forward-Port-Of: odoo/odoo#266369 Forward-Port-Of: odoo/odoo#265552
This update fixes a visual issue where the background color of selected table cells wasn't accurately reflected in the toolbar. The changes include a new background color processor and adjustments to ensure the selected color is always updated, even when selecting empty cells. This improves the user experience when working with tables in the HTML editor.
Original PR description
Before this commit: the background color of selected table cells isn't shown in the toolbar. After this commit: we have a background color processor in the table plugin to calculate the background color of selected cells. The color and background color are also properly reset to update the selected color when selecting an empty table cell. table_selectionchange_handlers is created to make sure the selected color is updated after it. task-5976046 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267342 Forward-Port-Of: odoo/odoo#252011
This update corrects a bug in the helpdesk rating dashboard. Previously, ratings created late in the day weren't included in searches. The change now uses current date and time to ensure all ratings within the last 7 days are accurately reflected, providing a more complete view of customer feedback.
Original PR description
Before this commit, the ratings created the current date at 23h will not been taken into account in helpdesk rating dashboard. This commit uses datetime.now() instead of date.today() to search the ratings in the last 7 seven days. runbot-error-230905 Forward-Port-Of: odoo/enterprise#119035
This update resolves a visual glitch where a gradient color filter remained on website sections after the background image was removed. The fix directly removes the related filter element, ensuring a cleaner and more consistent appearance for website pages. This improves the user experience and prevents unexpected visual artifacts.
Original PR description
Steps to reproduce: - Edit a website page. - Select a section with a background image. - Set a gradient color filter on the background image. - Remove the background image. => The gradient color filter stays in the section DOM. After this commit, `removeBackgroundImage` directly removes the related `.o_we_bg_filter`. Forward-Port-Of: odoo/odoo#265025
This update ensures that users aren't presented with warnings related to the Italian EDI (l10n_it_edi) functionality if it's not applicable to their business. Previously, warnings would appear even when the EDI setting was correctly configured. This change improves the user experience by removing irrelevant notifications.
Original PR description
We shouldn't show warnings for `l10n_it_edi` if it's not possible to use it, even if the partner has its preferred EDI method set as `it_edi_xml`. Ticket [link](https://www.odoo.com/odoo/project.task/5985570) opw-5985570 Forward-Port-Of: odoo/odoo#267019
This update resolves an issue where clicking on a binary field in a list view would unexpectedly open the associated record. The change prevents this behavior, ensuring users only download the intended binary content. Unit tests have been added to guarantee this fix.
Original PR description
If a list view contains a field (column) with binary widget, on click it will download the content of the field. This is the intended behavior but at the same time it will, by default, open the record of which it is part, which is strange since the user only wants to download the content. With this PR we make use of .stop on the t-on-click to detach the execution of the function from the opening of the record. We also add unit tests for this. Task: 6260266 Forward-Port-Of: odoo/odoo#267197
This update corrects an issue where the graph view incorrectly displayed currency conversions when only one company was present. The fix prevents unnecessary currency conversions, ensuring that graph data consistently shows the correct currency (USD) regardless of the grouping options. This improves the accuracy and reliability of sales reporting.
Original PR description
Steps to reproduce ================== - Install sale_managemement - Enable the EUR currency - Create a new company with the EUR currency - Enable both the current and the new company as the main one - Go to Sales - Switch to the graph view - Group by Order Date > year - Hover over a bar => The currency is in USD - Group by Order Date > Week => The currency is now in EUR even though all records are in USD Cause of the issue ================== _web_read_group_fill_temporal returns an empty array in currency_id:array_agg_distinct when there are no records in that group The undefined currency was then added to graphCurrencies. => graphCurrencies = [1, undefined] Since graphCurrencies has more than one item, the currencies are converted opw-6226827 Forward-Port-Of: odoo/odoo#267608 Forward-Port-Of: odoo/odoo#266972
This update allows users to efficiently edit the analytics distribution field within asset records, mirroring the functionality available for journal items. This enhancement streamlines the process of updating asset analytics data, improving user productivity and data accuracy.
Original PR description
This commit fixes the multi-edit of analytics distribution field in assets form view. The multi-edit option was added to the analytics distribution widget, same as in the journal items. task-6218188 Forward-Port-Of: odoo/enterprise#119054 Forward-Port-Of: odoo/enterprise#118042
This update resolves a technical issue related to how automatic sign fields are populated. The change isolates the auto-fill process to prevent unintended side effects that could have disrupted the signing workflow. This ensures a more reliable and consistent experience for users completing digital signatures.
Original PR description
task-6269354
This update resolves an issue where the Executive Summary report would crash when the date range filter was disabled. The fix ensures the report uses the fiscal year's start date instead, preventing a calculation error and allowing the report to function correctly regardless of the date range selection.
Original PR description
## Steps to Reproduce: 1. Install the Accounting module. 2. Go to Accounting > Reporting > Executive Summary. 3. Activate debug mode. 4. Click on the gear icon at the top. 5. In the "Options" tab,…
## Steps to Reproduce: 1. Install the Accounting module. 2. Go to Accounting > Reporting > Executive Summary. 3. Activate debug mode. 4. Click on the gear icon at the top. 5. In the "Options" tab, disable the "Date Range". 6. Open the report again. ## Error: `TypeError - unsupported operand type(s) for -: 'datetime.date' and 'NoneType'` ## Cause: At [1], when the "Date range" option is disabled in the summary report, `date_from` becomes None. The NDays expression still computes `date_to - date_from` at [2], which raises a TypeError because subtraction between a datetime and NoneType is not supported. ## Fix: This commit takes the fiscal-year's start date, when the date-range feature is disabled. [1] - https://github.com/odoo/enterprise/blob/a9cadd93b849375edfcc7fd04612d9eb8787043b/account_reports/models/account_report.py#L564-L570 [2] - https://github.com/odoo/enterprise/blob/a9cadd93b849375edfcc7fd04612d9eb8787043b/account_reports/models/executive_summary_report.py#L15-L16 sentry-7455506965 Forward-Port-Of: odoo/enterprise#116888
A recent test failure related to demo data installation has been resolved. The fix ensures that a simulation offer is hidden, preventing errors during the test run. This improves the stability of the system when using the standard demo environment.
Original PR description
**Problem**: The test fails when demo data is installed because some steps expect an empty list view. **Fix**: Ensure the simulation offer is hidden by applying a custom filter on the simulation employee Task: 6246575 Forward-Port-Of: odoo/enterprise#119065 Forward-Port-Of: odoo/enterprise#118358
This update resolves a performance issue impacting the calculation of payroll deductions (DPV) in the Belgian HR payroll module. The fix optimizes a key process, leading to faster and more efficient payroll processing. This ensures accurate and timely payroll calculations for our business users.
Original PR description
Forward-Port-Of: odoo/enterprise#118929
This update fixes an issue where orders placed at tables in one restaurant POS configuration were sometimes incorrectly matched and merged by other configurations sharing the same floor. This ensures accurate order tracking and prevents duplicate order processing, improving operational efficiency. The change was made as part of a routine bug fix.
Original PR description
When multiple POS configurations share the same restaurant floor, an order placed on a table in one POS could be incorrectly retrieved or merged by another POS selecting the same table. task-id: 6024012 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253473 Forward-Port-Of: odoo/odoo#253116
This update optimizes the timesheet grid by preventing unnecessary reloading of the entire form when focusing on the timer field. By handling focus directly within the timer widget, the system now only updates the specific field, resulting in a smoother and faster user experience. This change improves performance and responsiveness.
Original PR description
This PR prevents re-rendering the whole systray form view when focusing in and out of the timer field. We instead handle the focus in the widget, ensuring only the field itself re-renders. Task-6251180 Forward-Port-Of: odoo/enterprise#118524
This update fixes an issue where multiple lines of text were incorrectly separated into individual code or quote blocks when converting to a single block. The change ensures that selected text is now correctly combined into a single code or quote block, improving the editor's functionality and user experience. This resolves a visual inconsistency and streamlines content formatting.
Original PR description
Steps to reproduce: - Write multiple lines of text. - Select all lines. - Change block type from Normal to Code (or Quote) via the toolbar. Description of the issue: - Notice that each line is now a separate code block (or quote). Cause: - The `setBlock` method currently converts each selected block individually into the target block type, creating multiple blocks when multiple lines are selected. Solution: - For code and quote blocks, `setBlock` now converts only the first selected block into the target type and merges the content of the other selected blocks into it, ensuring a single code/quote block. task-6068930 Forward-Port-Of: odoo/odoo#258331
This update fixes an issue where the duration of calendar events created through the quick-create form wasn't updating correctly after modifying the end time. Now, when you adjust the event's end time in the popover and open the full form, the duration will accurately reflect the new end time, ensuring event details are always precise.
Original PR description
When creating a calendar event by dragging on the calendar view, modifying the end time in the quick-create popover, and then clicking "More Options", the duration shown in the full form is the…
When creating a calendar event by dragging on the calendar view, modifying the end time in the quick-create popover, and then clicking "More Options", the duration shown in the full form is the original drag value instead of the value implied by the user's updated stop. calendar's makeContextDefaults seeds default_start, default_stop, default_duration, and default_allday from the drag extent. In the quick-create popover, changing stop triggers _compute_duration on that record so its duration becomes correct. On "More Options", goToFullEvent extracts a whitelist of fields from the quick-create record as default_X and merges them with the original drag context. https://github.com/odoo/odoo/blob/c82341c503ac/addons/calendar/static/src/views/calendar_form/calendar_quick_create.js#L9-L19 duration is missing from that whitelist, so the merged context still carries the stale default_duration from the drag. In the full form, that default is applied to the duration field and _compute_duration does not run because a default was provided for a stored, writable field. Adding duration to the whitelist forwards the quick-create's recomputed value as default_duration so the full form opens with the correct duration. Steps to reproduce: 1. Open Calendar, drag to create a 2-hour event (e.g. 10:00-12:00) 2. In the quick-create popover, change the end time to 14:00 3. Click "More Options" 4. Check the Duration field in the full form => Duration shows the original drag value (02:00) instead of 04:00 opw-6087449 Forward-Port-Of: odoo/odoo#257294
Features or functions removed from Odoo
This update removes a reference to 'Peppol' from the French Payroll (l10n_fr_pdp) module. This change simplifies the configuration and aligns with evolving regulations, ensuring clarity for users and reducing potential confusion. The removal does not impact core functionality.
Original PR description
task-None Forward-Port-Of: odoo/odoo#267650
Code cleanup and technical improvements
This update enhances the way timesheets display floating values by making it easier to customize the formatting options. This change improves the flexibility and adaptability of timesheet reporting, allowing for more tailored views. It's a minor update that ensures consistent and accurate time tracking.
Original PR description
This PR slightly refactors the FloatTime widget to create a getter for the formatting options of its value and popover, which not only is a DRY-positive thing, but also allows us to override it more easily in Timesheets Task-6251180 Forward-Port-Of: odoo/odoo#266743
24 changes
New functionality added to Odoo
This update enhances the Odoo Enterprise payroll system by allowing for more flexible adjustments to individual payslip lines. This change improves the accuracy and customization of payroll calculations for employees. The update modifies related models and views to support these new editing capabilities.
Resolved issues and error corrections
This update fixes an issue where users couldn't reliably select formatted text within a table cell. The fix simplifies the selection process by directly verifying cell boundaries, ensuring consistent and accurate cell selection across the HTML editor. This enhances the user experience when working with tables.
Original PR description
### Steps to reproduce: - create a table (e.g. /table) - type something in any cell and select that cell. - apply formatting through toolbar (bold, italic, etc.) - now select that single cell through…
### Steps to reproduce: - create a table (e.g. /table) - type something in any cell and select that cell. - apply formatting through toolbar (bold, italic, etc.) - now select that single cell through mouse. - observe that it is not selected ### Description of the issue/feature this PR addresses: - The single-cell selection logic relied on getTargetedNodes(), which collects descendants of the selection’s common ancestor. When selecting text inside inline formatting tag (e.g. `<i>`), the text node became the common ancestor, so the parent `<i>` tag was excluded from selectedNodes. As a result, check ensuring all cell elements were selected failed, preventing from being selected. ### Desired behavior after PR is merged: - Cell selection was simplified using areNodeContentsFullySelected(startTd) directly instead of manually matching targeted descendants. This relies on DOM Range to verify whether the cell boundaries are fully selected. task-6207941 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266208 Forward-Port-Of: odoo/odoo#263742
This update optimizes the styling of the Odoo Enterprise home menu by replacing inefficient CSS selectors with CSS variables. This change improves page loading speed and overall performance, leading to a smoother user experience. The update addresses a performance issue related to hover and active states.
Original PR description
Avoid selectors after `:hover` and `:active`, as they can impact performance. CSS variables are now used instead. Replace hex color values with "0 0 0" RGB syntax to ensure compatibility with CSS variable usage. Forward-Port-Of: odoo/enterprise#119082
This update resolves an issue where clicking on binary data within a list view would also open the associated record. We've implemented a change to prevent this automatic opening, ensuring users only download the desired file content. Unit tests have been added to guarantee this fix.
Original PR description
If a list view contains a field (column) with binary widget, on click it will download the content of the field. This is the intended behavior but at the same time it will, by default, open the record of which it is part, which is strange since the user only wants to download the content. With this PR we make use of .stop on the t-on-click to detach the execution of the function from the opening of the record. We also add unit tests for this. Task: 6260266 Forward-Port-Of: odoo/odoo#267197
This update fixes an issue where timesheet forms weren't loading correctly after refreshing a page. Now, when you view a timesheet entry, the correct, detailed form view is displayed, ensuring accurate data access. This improves the user experience for timesheet management.
Original PR description
…m view * Go to Timesheets > My Timesheets > switch to Grid view. * Hover over a cell with a timesheet entry and click the magnifier (search) icon. * The list opens; click a record to open its form view. * Observe the URL: `/odoo/timesheets/account.analytic.line/<id>`. * Refresh the page (F5). Before this commit, the generic form view was shown instead of the timesheet-specific form view. This occurred because, when reloading a page with a dynamic action and a resId, a generic view layout [false, "form"] was requested instead of the action-defined view. Now, the dynamic action is properly restored on refresh, ensuring the correct specific view is loaded for the form. opw-6133602 Forward-Port-Of: odoo/odoo#266369 Forward-Port-Of: odoo/odoo#265552
This update optimizes how Odoo recalculates styles in large tables, like the Accounting > Balances Sheets. By using a more targeted approach, the system now responds faster during window resizing, scrolling, and sorting, leading to a smoother user experience. This change improves overall performance and responsiveness.
Original PR description
Avoid using the :has() selector and use a specific class on the body instead to replicate the same behavior. This reduces work during the "Recalculate Style" phase (for example when hovering rows in large tables such as the Accounting > Balances Sheets). It lowers recalculation time during window resizes, heavy scrolling, and table sorting by preventing broad selector matches and limiting style checks to elements with the specific class. 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#267602 Forward-Port-Of: odoo/odoo#267170
This update resolves an issue where the Documents app incorrectly displayed a duplicate PDF preview when receiving XML attachments via email. The fix ensures that the preview accurately shows the PDF content, addressing a visual inconsistency. This improvement enhances the user experience when accessing documents from email.
Original PR description
**Steps to reproduce:** - Install documents_account - Set up alias to catch incoming mails - Receive a mail with xml attachement which can be previewed as pdf - Go to Documents app - Click on the…
**Steps to reproduce:** - Install documents_account - Set up alias to catch incoming mails - Receive a mail with xml attachement which can be previewed as pdf - Go to Documents app - Click on the document preview - Preview is split in two iframes, both with the same content (pdf) **Issue:** Due to the `isPdf` patch the attachment can match multiple types for the preview (pdf and text) as both getter return `true`. ``` <iframe t-if="state.file.isPdf" ... <iframe t-if="state.file.isText" ... ``` It also seems that xml received by mail are imported as text, which is why the issue doesn't happen when manually uploading the same xml file. **Fix:** Ensure that if the document is matching `isPdf`, it doesn't trigger the second iframe with `isText`. Also it seems fixed in 19.0 as the text iframe is replaced by this xpath: `<xpath expr="//iframe[@t-if='state.file.isText']" position="replace">` which was added for https://github.com/odoo/enterprise/commit/de614ee5e9a087d49939c65c0118ae6164c7b31b related patch: https://github.com/odoo/enterprise/commit/ffcdd2275c8bf564e15151ccbcaf3965ed968450 opw-6018536 Forward-Port-Of: odoo/enterprise#118041 Forward-Port-Of: odoo/enterprise#112041
This update fixes a bug in the helpdesk rating dashboard. Previously, ratings created late in the day weren't accurately reflected in searches. The change now uses the current date and time for searching, ensuring all recent ratings are included in the dashboard view.
Original PR description
Before this commit, the ratings created the current date at 23h will not been taken into account in helpdesk rating dashboard. This commit uses datetime.now() instead of date.today() to search the ratings in the last 7 seven days. runbot-error-230905 Forward-Port-Of: odoo/enterprise#119035
This update resolves a situation where users would receive warnings related to the Italian EDI (SdI) functionality even when it wasn't applicable. Now, the system only displays these warnings when the company is actually configured for Italian EDI processing, ensuring a cleaner user experience.
Original PR description
We shouldn't show warnings for `l10n_it_edi` if it's not possible to use it, even if the partner has its preferred EDI method set as `it_edi_xml`. Ticket [link](https://www.odoo.com/odoo/project.task/5985570) opw-5985570 Forward-Port-Of: odoo/odoo#267019
This update resolves a visual issue in the Gantt holiday view, specifically a problematic background color in dark mode. It also corrects a previous issue where the selection of holidays was incorrectly counting records instead of the number of selected cells, ensuring accurate holiday management.
Original PR description
- changed selected value in the view to be number of selected cells instead of number of selected records - fixed a visual bug in dark mode where the create popup has ugly background task-id: 6124765
This update corrects a recent change that unintentionally removed a styling class from all dynamic website snippets. The previous fix, intended for mono-record snippets, was too broad. This commit restores the correct styling for all dynamic snippets, ensuring consistent layout and appearance on the website.
Original PR description
Before [1], the `s_dynamic_snippet_row` class was added to all dynamic snippets using the `website.s_dynamic_snippet.grid` template and defining `columnClasses` values. In [1], a fix was introduced to prevent adding this class on mono-record snippets, as it was breaking the layout when used inside small containers (`o_container_small`). However, the condition introduced by that fix is too broad and currently removes the class from all dynamic snippets. This commit fixes the condition so that `s_dynamic_snippet_row` is only excluded from mono-record snippets, restoring the intended layout for other dynamic snippets. [1]: https://github.com/odoo/odoo/commit/fe2279f760adc6a53ba2242961f3873a5d3215dd Forward-Port-Of: odoo/odoo#265362 Forward-Port-Of: odoo/odoo#264407
This update fixes a limitation in how analytics data is managed for assets. It now allows users to simultaneously edit multiple analytics distribution values within the asset form, mirroring the functionality available for journal items. This streamlines the process of updating and analyzing asset performance data.
Original PR description
This commit fixes the multi-edit of analytics distribution field in assets form view. The multi-edit option was added to the analytics distribution widget, same as in the journal items. task-6218188 Forward-Port-Of: odoo/enterprise#119054 Forward-Port-Of: odoo/enterprise#118042
This update fixes an issue where multiple lines of text were being converted into separate code or quote blocks instead of a single block. The fix ensures that selecting multiple lines and changing the block type results in a unified code or quote block, improving the editor's functionality and consistency.
Original PR description
Steps to reproduce: - Write multiple lines of text. - Select all lines. - Change block type from Normal to Code (or Quote) via the toolbar. Description of the issue: - Notice that each line is now a separate code block (or quote). Cause: - The `setBlock` method currently converts each selected block individually into the target block type, creating multiple blocks when multiple lines are selected. Solution: - For code and quote blocks, `setBlock` now converts only the first selected block into the target type and merges the content of the other selected blocks into it, ensuring a single code/quote block. task-6068930 Forward-Port-Of: odoo/odoo#258331
This update resolves a technical error that occurred when PL companies attempted to pay non-VAT PL suppliers with invoices exceeding 15,000 PLN. The fix prevents unnecessary verification processes, ensuring smoother payment processing for these suppliers. This improves the reliability of the bank verification system.
Original PR description
[FIX] l10n_pl_bank_verification: PL Supplier no VAT When a PL supplier has no VAT and a PL company tries to pay him a bill above 15.000 PLN, there is a traceback. The reason is that there was no check for partner with no VAT, a verification was created every time the field was compute. Forward-Port-Of: odoo/odoo#266878
This update strengthens Odoo.com's subscription verification process by adding a check for duplicated SAAS databases that have been neutralized. Previously, test databases could incorrectly pass subscription checks, leading to potential issues. This change ensures accurate subscription validation for all Odoo.com users.
Original PR description
Odoo.com does not create a distinction between a production and duplicated SAAS database. This allows test databases to pass the check for subscription. This commit adds an additional check for duplicated SAAS databases with a neutralised status. task-6249752 Forward-Port-Of: odoo/enterprise#118281
This update corrects a formatting problem in invoices generated when 'Hide composition' is enabled. Previously, columns after the description were misaligned, causing a visually incorrect invoice PDF. This fix ensures invoices are displayed correctly for German companies using the l10n_din5008 module.
Original PR description
| Before | After | |--------|--------| | <img width="1573" height="830" alt="image" src="https://github.com/user-attachments/assets/1960b51b-5c3e-4560-bd09-a20adfe2b381" /> | <img width="1573" height="830" alt="image" src="https://github.com/user-attachments/assets/565d0238-a295-44b7-bdaa-e7c6dd1200cf" /> | Steps to reproduce ================== - Install l10n_din5008,l10n_de - Use a german company - Go to settings - Enable "Show Position Column in Reports" - Go to Invoicing > Sales > New - Add a new section - Click on the three dots - Check "Hide composition" - Add a new line with a product - Confirm the Journal Entry - Print the Invoice PDF => Every column after the description is offset by one opw-5427590 Forward-Port-Of: odoo/odoo#261527
This update ensures that file uploads initiated through the link popover are immediately canceled when the user discards the popover. Previously, uploads continued in the background even after the discard button was pressed, leading to potential data inconsistencies. This change improves the user experience by preventing unexpected uploads.
Original PR description
**Current behavior before PR:** Steps to reproduce the issue: - Go to Todo, In the network tab switch to "Slow 4G" so that file upload can take few seconds to upload. - Upload a file using link popover. - While the file upload is in progress, hit the discard button of the link popover. - Notice that the upload continues in the background and when it completes successfully, link is inserted. **Desired behavior after PR is merged:** Discarding the link popover during file upload should cancel the upload request and prevent inserting the link. task-6199113 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267611 Forward-Port-Of: odoo/odoo#263463
This update fixes an issue where the project template dropdown in demo mode had a cluttered appearance, making it difficult to read. The fix removed a styling element that caused text to overlap, ensuring a clean and consistent display for all users.
Original PR description
Steps to reproduce: == Login as demo/onboarding user Open Project app Click on New Observe the template dropdown list Issue: == The template dropdown items are rendered with collapsed row height and poor vertical spacing in demo mode, making the list hard to read. Cause: == The template dropdown items utilized the `pe-0` utility class, which removed the padding at the end of the element. For non-admin users this caused the template name to touch the right edge of the container. Fix: == Removed the `pe-0` from the `DropdownItem` to restore standard right-side padding, and ensure consistent and readable row heights for both Admin and Demo users. task-5338191 Forward-Port-Of: odoo/enterprise#104440
A recent test within the HR Holidays module failed due to an error in how it checked for recordsets with multiple records. This commit corrected the code to avoid this issue, preventing test failures when other modules are installed. This ensures the HR Holidays tests run reliably.
Original PR description
Before this commit, the line https://github.com/odoo/odoo/blob/saas-19.1/addons/hr_holidays/tests/test_holidays_mail.py#L69 used `.id` on a many to many recordset which failed when the recordset had multiple records. This test led to an error when installing other modules with demo data like `test_l10n_be_hr_payroll_account` and the test was run with demo data. This commit uses the `in` operator instead of `==` and avoids `employee_ids.id` to avoid the error. Runbot error: https://runbot.odoo.com/odoo/error/241106 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266677
This update fixes an issue where the cursor position was incorrect after moving content within the HTML editor. Now, when moving a table or paragraph, the cursor automatically adjusts to the beginning of the moved item, preserving the user's selection if it was within the moved content.
Original PR description
#### Description of the issue/feature this PR addresses: - MoveNode restores the cursor at the container end position - After moving a table, the cursor ends outside the table body #### Desired behavior after PR is merged: - Preserve the selection if it was inside the moved node - Otherwise place the cursor at the start of the moved node #### Steps to reproduce: - Create a table in the editor - Move the table using Movenode - Drop the table and check the cursor position - The cursor ends outside the moved table body - Select some text in a paragraph - Move that paragraph using Movenode - The selection is placed at the end of the moved node task-6215743 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267549 Forward-Port-Of: odoo/odoo#264264
This update corrects a flaw in how Odoo tracks device status (supported/unsupported). Previously, changes weren't consistently reflected in the database when a device switched between states. Now, device status changes are tracked separately, ensuring accurate database updates and preventing issues with device recognition.
Original PR description
When a device is marked unsupported (e.g. FDM after power outage) and becomes supported with the same identifier (e.g. FDM after the client restarts it after the power outage), the changed was not taken into account because we used to track changes in a set of supported + unsupported. We now track changes in supported and unsupported separately to make sure the db is informed of the changes.
This update resolves an issue where users without employee access rights couldn't search for timesheet versions. The change removes a restriction on accessing version fields, ensuring broader search functionality while maintaining security through a previously implemented bypass mechanism. This improves usability for all users.
Original PR description
Issue: ---------------------------------------- When searching for a field from `hr.version` without any rights on Employees, we get an access error. Steps to reproduce:…
Issue: ---------------------------------------- When searching for a field from `hr.version` without any rights on Employees, we get an access error. Steps to reproduce: ---------------------------------------- - Timesheet > To Validate > All timesheet - Filter on Employee > Department (is set for example) - An error pops up Cause: ---------------------------------------- The field `department_id` of `hr.employee` belongs to `hr.version` and is accessible through the `_inherits` and the field `version_id`. When doing the search above, during the optimization of the domain, we end up trying to read `department_id` on `hr.employee.version_id`. But the field `hr.employee.version_id` is not accessible to users without Employee access rights. They only have rights on the field `hr.employee.current_version_id`. This occurs from version saas-19.1 because the access check was added in this version. ([commit](https://github.com/odoo/odoo/commit/aa58663a271e24a1fcb3f59e6bddfac50054703c)) Solution: ---------------------------------------- We remove the group restriction on `version_id`. The group restrictions are done with the fields of `hr.version`. As `version_id` is only a computed field from `current_version_id` which has `bypass_search_access=True`, this should not expose any field that wasn't already. `bypass_search_access=True` was added on `current_version_id` for the same reason. ([src](https://github.com/odoo/odoo/commit/94bb4a29189400d6bd0c2ca97eba271601262e1b)) opw-6149198 opw-6251866 Forward-Port-Of: odoo/odoo#264953
This update fixes an issue where the duration of calendar events created via drag-and-drop wasn't accurately reflected in the full event form. Previously, the duration was stuck with the initial drag value. Now, the full form correctly displays the updated duration based on the user's final time selection, ensuring accurate event scheduling.
Original PR description
When creating a calendar event by dragging on the calendar view, modifying the end time in the quick-create popover, and then clicking "More Options", the duration shown in the full form is the…
When creating a calendar event by dragging on the calendar view, modifying the end time in the quick-create popover, and then clicking "More Options", the duration shown in the full form is the original drag value instead of the value implied by the user's updated stop. calendar's makeContextDefaults seeds default_start, default_stop, default_duration, and default_allday from the drag extent. In the quick-create popover, changing stop triggers _compute_duration on that record so its duration becomes correct. On "More Options", goToFullEvent extracts a whitelist of fields from the quick-create record as default_X and merges them with the original drag context. https://github.com/odoo/odoo/blob/c82341c503ac/addons/calendar/static/src/views/calendar_form/calendar_quick_create.js#L9-L19 duration is missing from that whitelist, so the merged context still carries the stale default_duration from the drag. In the full form, that default is applied to the duration field and _compute_duration does not run because a default was provided for a stored, writable field. Adding duration to the whitelist forwards the quick-create's recomputed value as default_duration so the full form opens with the correct duration. Steps to reproduce: 1. Open Calendar, drag to create a 2-hour event (e.g. 10:00-12:00) 2. In the quick-create popover, change the end time to 14:00 3. Click "More Options" 4. Check the Duration field in the full form => Duration shows the original drag value (02:00) instead of 04:00 opw-6087449 Forward-Port-Of: odoo/odoo#257294
Features or functions removed from Odoo
This update removes a reference to 'Peppol' from the French Payroll (l10n_fr_pdp) module. This change simplifies the configuration process and aligns with current regulatory requirements for French businesses. It ensures clarity and avoids potential confusion for users.
Original PR description
task-None Forward-Port-Of: odoo/odoo#267650
18 changes
Resolved issues and error corrections
This update fixes an issue where users couldn't reliably select formatted text within a table cell. The fix simplifies the selection process, ensuring that users can correctly select and format text within cells, regardless of inline formatting. This improves the overall usability of the table editor.
Original PR description
### Steps to reproduce: - create a table (e.g. /table) - type something in any cell and select that cell. - apply formatting through toolbar (bold, italic, etc.) - now select that single cell through…
### Steps to reproduce: - create a table (e.g. /table) - type something in any cell and select that cell. - apply formatting through toolbar (bold, italic, etc.) - now select that single cell through mouse. - observe that it is not selected ### Description of the issue/feature this PR addresses: - The single-cell selection logic relied on getTargetedNodes(), which collects descendants of the selection’s common ancestor. When selecting text inside inline formatting tag (e.g. `<i>`), the text node became the common ancestor, so the parent `<i>` tag was excluded from selectedNodes. As a result, check ensuring all cell elements were selected failed, preventing from being selected. ### Desired behavior after PR is merged: - Cell selection was simplified using areNodeContentsFullySelected(startTd) directly instead of manually matching targeted descendants. This relies on DOM Range to verify whether the cell boundaries are fully selected. task-6207941 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266208 Forward-Port-Of: odoo/odoo#263742
This update fixes an issue where automation rules using dotted paths to assign users to activities weren't working correctly. The change ensures that activity descriptions accurately reflect the assigned user, resolving a previous bug related to how Odoo handles relational field chains. This improves the reliability of automation workflows.
Original PR description
Steps to reproduce: ------------------------------------ 1. Install `ai` and `contacts` modules 2. Create an automation rule on Contact model: * Trigger: On Creation * Action To Do: Execute AI Action…
Steps to reproduce:
------------------------------------
1. Install `ai` and `contacts` modules
2. Create an automation rule on Contact model:
* Trigger: On Creation
* Action To Do: Execute AI Action
* Add a server action tool with 'Create Next Activity' action
* Set Activity User Type to Dynamic
* Set User Field to a dotted path (e.g., user_ids or partner_id.user_id)
3. Create a contact with a linked user
Observation:
------------------------------------
The activity description in the toast message fails to retrieve the user when using dotted field paths
Issue:
------------------------------------
The direct field access `record[self.activity_user_field_name]` in `_ai_get_action_description` method doesn't support dotted paths like 'partner_id.user_id'. This causes the same issue as in the mail module where relational field chains cannot be traversed
Solution:
------------------------------------
Use `record.mapped()` to support dotted paths by traversing the relational chain, consistent with the fix applied to the mail module
opw-6191715
Related Community PR: https://github.com/odoo/odoo/pull/263530
Forward-Port-Of: odoo/enterprise#118921This update optimizes the styling of the Odoo Enterprise website's home menu for faster loading times. By replacing specific CSS selectors with CSS variables, the changes reduce unnecessary processing and improve overall website performance. This results in a smoother user experience.
Original PR description
Avoid selectors after `:hover` and `:active`, as they can impact performance. CSS variables are now used instead. Replace hex color values with "0 0 0" RGB syntax to ensure compatibility with CSS variable usage. Forward-Port-Of: odoo/enterprise#119082
This update resolves an issue where clicking on binary data within a list view would unexpectedly open the related record. We've implemented a change to prevent this behavior, ensuring users only download the desired data. Unit tests have been added to guarantee this fix.
Original PR description
If a list view contains a field (column) with binary widget, on click it will download the content of the field. This is the intended behavior but at the same time it will, by default, open the record of which it is part, which is strange since the user only wants to download the content. With this PR we make use of .stop on the t-on-click to detach the execution of the function from the opening of the record. We also add unit tests for this. Task: 6260266 Forward-Port-Of: odoo/odoo#267197
This update fixes an issue where the timesheet form view wasn't correctly displayed after refreshing a page. Previously, a generic form view was shown instead of the specific timesheet form. Now, the system automatically loads the correct timesheet form view on refresh, ensuring users see the intended data.
Original PR description
…m view * Go to Timesheets > My Timesheets > switch to Grid view. * Hover over a cell with a timesheet entry and click the magnifier (search) icon. * The list opens; click a record to open its form view. * Observe the URL: `/odoo/timesheets/account.analytic.line/<id>`. * Refresh the page (F5). Before this commit, the generic form view was shown instead of the timesheet-specific form view. This occurred because, when reloading a page with a dynamic action and a resId, a generic view layout [false, "form"] was requested instead of the action-defined view. Now, the dynamic action is properly restored on refresh, ensuring the correct specific view is loaded for the form. opw-6133602 Forward-Port-Of: odoo/odoo#266369 Forward-Port-Of: odoo/odoo#265552
This update resolves an issue where paying PL suppliers without VAT exceeding 15,000 PLN would trigger a traceback. The fix adds a check to prevent unnecessary verification creation when a supplier lacks VAT, improving system stability and preventing errors.
Original PR description
[FIX] l10n_pl_bank_verification: PL Supplier no VAT When a PL supplier has no VAT and a PL company tries to pay him a bill above 15.000 PLN, there is a traceback. The reason is that there was no check for partner with no VAT, a verification was created every time the field was compute. Forward-Port-Of: odoo/odoo#266878
This update corrects a previous issue where helpdesk ratings weren't properly considering the current date and time. The change uses the current datetime to search ratings, ensuring that feedback from the last seven days is accurately reflected in the helpdesk rating dashboard. This improves the accuracy of reporting and analysis.
Original PR description
Before this commit, the ratings created the current date at 23h will not been taken into account in helpdesk rating dashboard. This commit uses datetime.now() instead of date.today() to search the ratings in the last 7 seven days. runbot-error-230905 Forward-Port-Of: odoo/enterprise#119035
This update fixes an issue where group holiday accruals were incorrectly showing as zero when the allocation start date was in the past. The change ensures that accrual calculations are properly triggered and displayed, regardless of the start date, providing accurate holiday allocation amounts.
Original PR description
Problem ------------------ When creating group allocations, when the allocation type is accrual and the start date is set in the past, the newly created allocations have the accrual amounts at 0. To…
Problem ------------------ When creating group allocations, when the allocation type is accrual and the start date is set in the past, the newly created allocations have the accrual amounts at 0. To reproduce: 1. Create an accrual plan with an easily measurable milestone (e.g. 1 day every day) 2. From the allocations view -> New Group Allocation 3. Enter the following values: Grant -> By Employee Employees -> select your employee Time Off Type -> Paid Time Off (doesn't matter too much) Allocation Type -> Based on Accrual Plan Validity Period -> any date a few days in the past (Personally I tested with 1/1/2025 and no end date) Allocation -> Keep at 0 Allocate Time Off 4. Go to the newly created allocation The allocation amount is 0. Reason ---------------------- When creating group allocations, the `hr.leave.allocation.generate.multi.wizard` calls the `_process_accrual_plans()` method to compute the accruals, but when the allocations are created, the nextcall and lastcall fields are set, so the accruals are not computed and the scheduled action also does nothing until the nextcall date. The onchange method manually sets the nextcall date to False so the accruals are processed. Solution ------------------ Created a method to get the fields that need to be set to calculate the initial accrual amounts from the start date, which is called both in the onchange and to batch write in the wizard before accrual plans are processed. The wizard checks the duration values before overwriting the number_of_days field, since user manually setting the amount should overwrite the calculations. task-4938695 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#267305 Forward-Port-Of: odoo/odoo#265783
This update ensures that users aren't presented with warnings related to the Italian EDI (l10n_it_edi) functionality if it's not applicable to their business. Previously, warnings would appear even when the EDI setting was correctly configured. This change improves the user experience by only displaying relevant information.
Original PR description
We shouldn't show warnings for `l10n_it_edi` if it's not possible to use it, even if the partner has its preferred EDI method set as `it_edi_xml`. Ticket [link](https://www.odoo.com/odoo/project.task/5985570) opw-5985570 Forward-Port-Of: odoo/odoo#267019
This update fixes a problem where reports downloaded in Safari (specifically with the German language setting) were generating files with an incorrect name. The issue stemmed from a formatting error in the date-based filename generation, which wasn't properly handled by Safari's rendering. This ensures reports download correctly for all users.
Original PR description
**STEP TO REPRODUCE** 1. On safari 2. Switch language to German. 3. On the general Ledger, select a custom date range. 4. Download the pdf/xslx 5. Notice the file have the name `example.com` instead of the intented name. **CAUSE** Since 19.0, we use the date to generate the file name. There is a regex used to format the date range, but it doesn't catch some date format like `DD.MM.YYYY`, which some localisation used. In such case, we use a string which contains a `\n` character to build the filename. This doesn't work on safari, leading to the file defaulting to `example.com` opw-6194841 Forward-Port-Of: odoo/enterprise#116635
This update fixes an issue where extra spaces in code blocks within the To-Do creation feature were incorrectly displayed as ` ` characters. The fix converts these spaces to regular spaces before syntax highlighting, ensuring code blocks render correctly and consistently. This improves the user experience when creating and editing code within the application.
Original PR description
Step to reproduce: - Go to To-Do → Create New - Type text with multiple consecutive spaces in the same line - In the same line → insert a /code block Description of the issue: Multiple spaces are converted into ` ` inside the code block. Cause: When the code block is processed for syntax highlighting, its `innerHTML` is used as the source text. During this process, ` ` is not handled as a result it remains as literal text, so syntax highlighting displays ` ` instead of a normal space. Solution: Convert ` ` into a normal space before the content is used for syntax highlighting. task-6184686 Forward-Port-Of: odoo/odoo#263053
This update disables the '@' mention feature for visitors in live chat conversations. Previously, visitors could trigger irrelevant suggestions, creating noise. This change ensures a cleaner and more focused chat experience for all users.
Original PR description
**Description of the issue this PR addresses:** ---------------------------------------------- Visitors in livechat can trigger partner mention suggestions by typing the @ delimiter in the composer.…
**Description of the issue this PR addresses:** ---------------------------------------------- Visitors in livechat can trigger partner mention suggestions by typing the @ delimiter in the composer. However, visitors can only mention themselves or odoobot, which does not provide meaningful functionality in the context of a livechat conversation. **Current behavior before PR:** ---------------------------------------------- - Visitors can type @ in the livechat composer and trigger partner mention suggestions. - The suggestions only include the visitor themselves or odoobot. **Desired behavior after PR is merged:** ---------------------------------------------- - The @ delimiter is disabled for visitors in livechat threads. - Partner mention suggestions are no longer triggered for visitors. - Internal users (operators) can still use @ mentions normally. Task-5119068 ---------------------------------------------- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267566 Forward-Port-Of: odoo/odoo#253551
This update fixes a previous limitation where channel owners without system admin privileges couldn't promote members to admin roles. The change ensures that channel owners can now correctly assign admin permissions, improving channel management capabilities. This resolves a technical issue impacting channel governance.
Original PR description
`canSetAdmin` was checking the target member role instead of the current user's role. Because of that, a channel owner who was not a system admin could not promote another member to admin. task-6250058
This update corrects a visual issue in German invoices (DIN5008) where columns were misaligned after hiding the item composition. Enabling the 'Show Position Column in Reports' setting resolved this, ensuring invoices print with correctly aligned data. This improves the professional appearance and accuracy of invoices for German customers.
Original PR description
| Before | After | |--------|--------| | <img width="1573" height="830" alt="image" src="https://github.com/user-attachments/assets/1960b51b-5c3e-4560-bd09-a20adfe2b381" /> | <img width="1573" height="830" alt="image" src="https://github.com/user-attachments/assets/565d0238-a295-44b7-bdaa-e7c6dd1200cf" /> | Steps to reproduce ================== - Install l10n_din5008,l10n_de - Use a german company - Go to settings - Enable "Show Position Column in Reports" - Go to Invoicing > Sales > New - Add a new section - Click on the three dots - Check "Hide composition" - Add a new line with a product - Confirm the Journal Entry - Print the Invoice PDF => Every column after the description is offset by one opw-5427590 Forward-Port-Of: odoo/odoo#261527
This update resolves issues within the l10n_fr_pdp module's demo mode, specifically by bypassing unnecessary authentication steps and preventing the forced use of two-factor authentication. Additionally, it corrects a technical error related to how documents are sent, ensuring proper handling regardless of whether the user is a standard Peppol user or a PDP user. This improves the reliability and usability of the demo environment.
Original PR description
And don't force the totp in demo mode Also, fix the mocking of the send_documents when sending documents with a Peppol User and not a PDP one. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267461
This update resolves a technical issue where duplicating floor screens in the backend caused errors during POS rendering. To ensure stability, the system now prevents the duplication of floor screens on the backend, improving the reliability of the restaurant point-of-sale system.
Original PR description
Duplicating a floor screen causes a duplicated key exception when rendering the POS. To avoid this issue, duplication on the backend is not allowed. task-6246748
This update ensures that errors related to intrastat code assignment are only triggered when product templates have specific characteristics – namely, dynamic attributes and no variants. Previously, the system incorrectly flagged this scenario, now the validation process is more precise, preventing unnecessary errors and streamlining product setup.
Original PR description
Problem: When saving an intrastat code on a product template with no variants, an error should be raised because intrastat codes are stored on the product variants. However, the error gets raised when creating a product template with intrastat code set because the variants get created after the product template is created, so it doesn't find any variant although the default variant will be created right after saving the product template. Solution: The constraint should only be triggered when saving the intrastat code on a product template with dynamic attributes and no variants. Since dynamic attributes are the only ones that can lead to a product template with no variants, we can check if the product template has dynamic attributes and no variants before raising the error. Forward-Port-Of: odoo/enterprise#118986
Features or functions removed from Odoo
This update removes a reference to 'Peppol' from the l10n_fr_pdp module. This change simplifies the configuration and reduces potential confusion for French businesses using the Odoo accounting system. It's a minor technical adjustment ensuring compliance and clarity.
Original PR description
task-None Forward-Port-Of: odoo/odoo#267650
1 change
Resolved issues and error corrections
This update resolves an issue where a validation error incorrectly triggered when setting intrastat codes on product templates. The fix ensures the error only appears when a product template lacks variants and uses dynamic attributes, preventing unnecessary errors and streamlining the product creation process. This improves data accuracy and user experience.
Original PR description
Problem: When saving an intrastat code on a product template with no variants, an error should be raised because intrastat codes are stored on the product variants. However, the error gets raised when creating a product template with intrastat code set because the variants get created after the product template is created, so it doesn't find any variant although the default variant will be created right after saving the product template. Solution: The constraint should only be triggered when saving the intrastat code on a product template with dynamic attributes and no variants. Since dynamic attributes are the only ones that can lead to a product template with no variants, we can check if the product template has dynamic attributes and no variants before raising the error. Forward-Port-Of: odoo/enterprise#118986
8 changes
Resolved issues and error corrections
This update resolves a technical issue in the appointment scheduling system that caused incorrect interval calculations. The fix ensures accurate interval inversion, addressing potential errors in scheduling and preventing disruptions to user workflows. The change includes new tests to guarantee correct functionality across various scenarios.
Original PR description
The [commit](https://github.com/odoo/enterprise/commit/53450065be0c3ec9d648d4fd39ec3a9a912bd06c) introduced the method for inverting the interval inside the given limits. The method was failing for the following edge cases: ```python >>> invert_intervals([(1, 2), (4, 5)], 0, 10) result - [(2, 4), (5, 10)] expected - [(0, 1), (2, 4), (5, 10)]? >>> invert_intervals([(-2, -1)], 0, 10) result - [(0, 10)] expected - same >>> invert_intervals([(11, 12)], 0, 10) result - [] expected - [(0, 10)] >>> invert_intervals([(-1, 1), (2, 5), (8, 12)], 0, 10) result - [(1, 2), (5, 8)] expected - same >>> invert_intervals([(2, 5), (8, 12)], 0, 10) result - [(5, 8)] expected - [(0, 2), (5, 8)] >>> invert_intervals([(2, 5), (11, 12)], 0, 10) result - [] expected - [(0, 2), (5, 10)] ``` This commit fixes the function to correctly handle all the cases. The test cases are also added to test all the edge cases. Forward-Port-Of: odoo/enterprise#107112
This update fixes an issue where the year calculation for weeks overlapping between years was incorrect, leading to unexpected results at the end of 2026. The change ensures that the year and week numbers are synchronized, resolving a potential data inconsistency and improving date accuracy. This ensures correct reporting and calculations related to time periods.
Original PR description
### Description of the issue/feature this PR addresses: getLocalYearAndWeek is used to get the year and week number for a given date. When a week overlaps 2 years, the week number is taken based on…
### Description of the issue/feature this PR addresses: getLocalYearAndWeek is used to get the year and week number for a given date. When a week overlaps 2 years, the week number is taken based on the year where the week has most days. So if a week has 5 days in year Y and 2 in Y+1. The week is taken counting from Y (probably week 53). If a week has 3 days in Y and 4 in Y+1, then the week number is reset to 1. The year, however did not follow the same logic, and was taken as the year of the last day of the ISO week. ### Current behavior before PR: At the end of 2026, this will cause problems because the week number will run as: * 2026, week 52 (all days in 2026, OK) * 2027, week 53 (most days in 2026, last day in 2027, Not OK) * 2027, week 1 (all days in 2027, OK) ### Desired behavior after PR is merged: This commit aims to solve this issue by following the same logic for week number and year, so that the end of 2026 will go as: * 2026, week 52 (no changes) * 2026, week 53 (year is not incremented if week number is not reset) * 2027, week 1 (no changes, but year is incremented when week number is reset) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267656
This update resolves an issue where paying a PL supplier without a VAT ID (over 15,000 PLN) would trigger a traceback. The fix adds a check to prevent unnecessary verification creation, ensuring smoother payment processing for suppliers without VAT.
Original PR description
[FIX] l10n_pl_bank_verification: PL Supplier no VAT When a PL supplier has no VAT and a PL company tries to pay him a bill above 15.000 PLN, there is a traceback. The reason is that there was no check for partner with no VAT, a verification was created every time the field was compute. Forward-Port-Of: odoo/odoo#266878
This update resolves an issue where users would see warnings related to the Italian EDI integration even when it wasn't applicable. Now, the system only displays these warnings when the company is actually configured for Italian EDI processing, ensuring a cleaner user experience and reducing unnecessary notifications.
Original PR description
We shouldn't show warnings for `l10n_it_edi` if it's not possible to use it, even if the partner has its preferred EDI method set as `it_edi_xml`. Ticket [link](https://www.odoo.com/odoo/project.task/5985570) opw-5985570 Forward-Port-Of: odoo/odoo#267019
This update resolves issues within the French PDP (pdp) module during demo mode, specifically by bypassing unnecessary authentication steps and preventing the forced use of two-factor authentication. Additionally, the system now correctly handles document sending for Peppol users, ensuring accurate processing. This improves the stability and usability of the demo environment.
Original PR description
And don't force the totp in demo mode Also, fix the mocking of the send_documents when sending documents with a Peppol User and not a PDP one. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267461
This update resolves an issue where Instagram videos weren't displaying correctly in website background blocks. The problem stemmed from an unnecessary addition of a URL parameter that was conflicting with Instagram's embed code. This fix removes that addition, ensuring Instagram videos now function as expected.
Original PR description
Steps to reproduce: =================== 1. Edit a page, add a Cover/Banner block. 2. Set its background to a video, paste an Instagram URL 3. Save and open the published page. => Instagram embed is…
Steps to reproduce: =================== 1. Edit a page, add a Cover/Banner block. 2. Set its background to a video, paste an Instagram URL 3. Save and open the published page. => Instagram embed is broken (iframe shows nothing / error). Cause: ======= Background videos broke for Instagram because the BackgroundVideo interaction unconditionally appends "&enablejsapi=1" to the iframe URL on start. Instagram embed URLs have no query string (`//www.instagram.com/p/<id>/embed/`), so the append produces `//www.instagram.com/p/<id>/embed/&enablejsapi=1` the `&` ends up in the path and Instagram refuses to render. The unconditional append is itself a regression from the public-widget → interaction refactor in [2]. The original code in 18.0 only added the param when `isYoutubeVideo && isMobileEnv`, as a workaround for old YouTube records that lacked it. Since [1], `enablejsapi=1` is already injected server-side in `html_editor/tools.py` / `web_editor/tools.py` when building YouTube autoplay embed URLs, so any YouTube background saved via the media dialog from 17.0 onward already has it. The JS append is redundant for YouTube and harmful for Instagram. Solution: ========= remove the unconditional append of `&enablejsapi=1` in the BackgroundVideo interaction [1]: https://github.com/odoo/odoo/commit/ca60af9dadc25adbc9eb159870ce1233a2886492 [2]: https://github.com/odoo/odoo/commit/b9b3a605e0f4 opw-6233081 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267016
This update ensures that attachments related to invoices (generated from sales) are correctly detached, allowing for easier XML regeneration. A previous issue prevented these attachments from being included in bulk exports. This change maintains proper functionality for Italian businesses requiring attachments for tax reporting.
Original PR description
The feature introduced in odoo/enterprise#78429 allows users to detach attachments from moves, primarily to facilitate the regeneration and re-sending of outgoing XMLs (e.g., sales invoices) without needing to delete the original attachment. However, detaching should not apply to incoming XML attachments on bills that originate from EDI import, as these attachments are the received source document and are never regenerated by the system. Detaching them inadvertently prevents their inclusion in bulk XML exports. An exception exists for Italy: businesses need to send Tax Integration XMLs back to the SdI. In this specific case, detaching the Tax Integration XML is appropriate and ensures the bulk export finds the latest, correct attachment. Ticket [link](https://www.odoo.com/odoo/project.task/5062132) opw-5062132 Forward-Port-Of: odoo/odoo#239701
This update corrects a problem affecting how the `pdp_verification_display_state` field is calculated, specifically within the partner merge wizard. The change replaces a problematic setting with a more reliable method, ensuring accurate data processing and preventing errors.
Original PR description
The computed field `pdp_verification_display_state` uses the `company_dependent` field. This causes an issue with the partner merge wizard in saas-18.2+. This commit fixes it by using the `depends_context` instead. runbot.build.error-939449 Forward-Port-Of: odoo/odoo#267481
3 changes
Resolved issues and error corrections
This update corrects a flaw in the appointment scheduling system that caused incorrect interval calculations. The fix ensures accurate interval inversion, addressing potential issues with date ranges and improving the reliability of appointment scheduling. New tests have been added to verify this correction.
Original PR description
The [commit](https://github.com/odoo/enterprise/commit/53450065be0c3ec9d648d4fd39ec3a9a912bd06c) introduced the method for inverting the interval inside the given limits. The method was failing for the following edge cases: ```python >>> invert_intervals([(1, 2), (4, 5)], 0, 10) result - [(2, 4), (5, 10)] expected - [(0, 1), (2, 4), (5, 10)]? >>> invert_intervals([(-2, -1)], 0, 10) result - [(0, 10)] expected - same >>> invert_intervals([(11, 12)], 0, 10) result - [] expected - [(0, 10)] >>> invert_intervals([(-1, 1), (2, 5), (8, 12)], 0, 10) result - [(1, 2), (5, 8)] expected - same >>> invert_intervals([(2, 5), (8, 12)], 0, 10) result - [(5, 8)] expected - [(0, 2), (5, 8)] >>> invert_intervals([(2, 5), (11, 12)], 0, 10) result - [] expected - [(0, 2), (5, 10)] ``` This commit fixes the function to correctly handle all the cases. The test cases are also added to test all the edge cases. Forward-Port-Of: odoo/enterprise#107112
This update ensures the growth comparison percentage calculation remains consistent regardless of the period order selected in reports. Previously, the calculation was sensitive to changes in period order due to outdated assumptions about data sorting. This fix improves the reliability and predictability of financial reporting.
Original PR description
The feature had originally been implemnted at a time where the period_order couldn't be modified, and always corresponded to what we call 'descending' now. Because of that, we assumed the column at index 0 was always the most recent period ; which caused the growth comparison percentage to change when switching period order. Forward-Port-Of: odoo/enterprise#118835
This update prevents Odoo from crashing when a product's barcode lookup returns a broken or missing image URL. The fix ensures that invalid URLs are gracefully handled, avoiding RPC errors and allowing users to continue using the product image functionality. This improves stability and user experience.
Original PR description
[FIX] product_barcodelookup: avoid crash on invalid image URLs **Steps to Reproduce:** - Install Sales module. - Configure a valid Barcode Lookup API key. - Create a product without an image. - Set a…
[FIX] product_barcodelookup: avoid crash on invalid image URLs
**Steps to Reproduce:**
- Install Sales module.
- Configure a valid Barcode Lookup API key.
- Create a product without an image.
- Set a barcode whose returned image URL is broken or returns HTTP 404
(e.g. `8426904171073`).
- Select the product and trigger the server action:
`Action -> Get Pictures from Barcode Lookup`
Issue:
**During image fetching:**
- Barcode Lookup API successfully returns product data and image URLs.
- `_get_image_from_url()` attempts to download the image.
- The image URL responds with HTTP 404.
- `barcode_lookup_request()` returns a dict for non-200 responses.
- `_get_image_from_url()` assumes the response is always a `requests.Response`
object and directly accesses: `response.status_code`
- This causes: `AttributeError: 'dict' object has no attribute 'status_code'`
**Root Cause:**
- `barcode_lookup_request()` returns inconsistent response types:
- `requests.Response` for successful requests
- `dict` for failed requests
- _get_image_from_url() does not handle the dict response before accessing
response attributes.
**Solution:**
- Make barcode_lookup_request() always return a One Response
object.
- Move the response validation to the callers instead of returning custom
dict objects.
**Result:**
- No RPC crash when image URLs are invalid or return 404.
- Broken image URLs are safely ignored.
**OPW-6200749**10 changes
New functionality added to Odoo
This update introduces the foundational localization package for North Macedonia within the Odoo Enterprise platform. This addition enables basic reporting and accounting features tailored to North Macedonian business requirements, expanding Odoo's reach to this market. It represents a key step in supporting local regulations and user needs.
Original PR description
This commit will add the basic package for north Macedonia task-5253778
Enhancements to existing features
This update hides the 'Targeted Job' field on the appraisal form for appraisees when no target job is set. This simplifies the form and reduces confusion for users, making the appraisal process more intuitive. The existing read-only behavior for non-managers remains unchanged.
Original PR description
Purpose: - Improve appraisal form usability by hiding the Targeted Job field for the appraisee when the field is empty and not editable. This PR includes: - Updated Targeted Job field visibility logic in the appraisal form. - Hidden the field for appraisees when no target job is configured. - Kept the existing readonly behavior unchanged for non-managers. task-6254850
This update enhances the Odoo website generator's ability to manage images by introducing a new attribute, 'data-ws-preserve'. This allows for customized image settings like shape and loading behavior, improving flexibility and control over how images are displayed. The underlying code has also been modernized for better clarity and maintainability.
Original PR description
Added the special attribute 'data-ws-preserve' on <img> that allows to set specific attributes despite the replacement with the regex. It is used to be able to add attributes like data-shape="..." or loading="eager".
This update enhances the Odoo Enterprise system to better support internal transfers between warehouses. Previously, generating delivery guides for these internal transfers was limited. Now, users can easily create delivery guides for transfers within their own warehouses, streamlining operations and improving efficiency.
Original PR description
Although less common than outgoing pickings, users sometimes need to generate it for transfers between their own warehouses. task-6107987
Resolved issues and error corrections
This update ensures that the l10n_id_reports module is properly configured for translation management within Odoo. By adding the module to the .weblate.json file, the system can now track and manage translations for this reporting module, improving its usability for users in countries that speak Icelandic.
Original PR description
Enable translation management by adding the module entry to .weblate.json. task-6239169 Forward-Port-Of: odoo/enterprise#118931
This update corrects a technical oversight where a new module for the Hungarian reports (l10n_hu_reports_a60) was developed but not properly integrated into the Weblate translation system. This ensures accurate translations are available for users in Hungary, preventing potential communication issues.
Original PR description
We added a new module here 379c5e9611f1f1c242027c1c134219966474de16 but forgot to add it to weblate.json for translation. no-task Forward-Port-Of: odoo/enterprise#118932
This update resolves an issue where the ellipsis indicator for long text messages didn't always update correctly in the Enterprise version of Odoo. The change utilizes a more efficient, reactive approach (signals) to ensure the indicator resets immediately when new text is added, improving the user experience.
This update corrects a problem where Odoo reports were displaying incorrectly when all company journals were assigned to a single ledger. The change removes the 'Local GAAP' implicit ledger from report selections, ensuring accurate reporting regardless of ledger configurations. This improves the reliability of financial reports.
Original PR description
When all journals of the company are in a ledger, the implicit ledger 'Local GAAP' is empty, so we remove it from the ledger selection in the reports. task-6260588 Forward-Port-Of: odoo/enterprise#118927
Code cleanup and technical improvements
This update resolves an issue where leave settings were incorrectly available when the time-off application wasn't used. The related code has been moved to a dedicated bridge module for better organization and to ensure functionality aligns with installed applications. This improves the overall stability and accuracy of leave calculations.
Original PR description
Issue: ------ The 'leave' and 'public_leave' values of 'hr.attendance.overtime.rule.timing_type' should not be available when time off app isn't installed. This PR also moves the `leave` and `public_leave` code to the `hr_holidays_attendance` bridge. odoo/odoo#259386 enterprise-108725 upgrade-9574 task-5942798
This update removes an outdated feature, `onWillUpdateProps`, which is no longer supported in the newer OWL3 version of Odoo. This change ensures the system continues to function correctly with the latest Odoo release, maintaining stability and performance. No functional changes were made.
2 changes
Resolved issues and error corrections
This update corrects a technical issue that was causing an assertion error related to product naming within the inter-company purchase order to sale order rules. The fix ensures consistent product naming across different Odoo modules, preventing the error and maintaining proper data flow between purchase and sales processes. This resolves a potential data inconsistency.
Original PR description
**Step to reproduce** Reproducible in single app The "name" field make this assertion fails: ``` self.assertRecordValues(sale_order.order_line[0], [{ "product_id":…
**Step to reproduce**
Reproducible in single app
The "name" field make this assertion fails:
```
self.assertRecordValues(sale_order.order_line[0], [{
"product_id": no_variant_product_tmpl.product_variant_id.id,
"name": 'No Variant\nAttribute: Value 1',
```
**Observation**
The name will not be the same depending which app are installed, purchase_product_matrix, changes the name of the product if there is a attribute value of a never variant:
https://github.com/odoo/odoo/blob/f399f99d4e0e562d25e1de32336e8d6a55199b9b/addons/purchase_product_matrix/models/purchase.py#L168-L174
Which will be passed to the purchase_order_line:
https://github.com/odoo/odoo/blob/f399f99d4e0e562d25e1de32336e8d6a55199b9b/addons/purchase/models/purchase_order_line.py#L630-L634
that will pass the information to the sale order:
https://github.com/odoo/enterprise/blob/bce04ce24b66fb1a2481274eb3aebdc30a62766e/sale_purchase_inter_company_rules/models/purchase_order.py#L114
https://github.com/odoo/enterprise/blob/bce04ce24b66fb1a2481274eb3aebdc30a62766e/sale_purchase_inter_company_rules/models/purchase_order.py#L125-L126
breaking commit : https://github.com/odoo/enterprise/commit/bf286a0005b8e22ffa717419cd2dfacff861a265
runbot-242362This update corrects a bug that caused growth comparison percentages to fluctuate when users switched the order of reporting periods. The original code incorrectly assumed a specific period order, leading to inconsistent calculations. This fix ensures accurate growth comparisons regardless of the selected period sequence.
Original PR description
The feature had originally been implemnted at a time where the period_order couldn't be modified, and always corresponded to what we call 'descending' now. Because of that, we assumed the column at index 0 was always the most recent period ; which caused the growth comparison percentage to change when switching period order. Forward-Port-Of: odoo/enterprise#118835
10 changes
Resolved issues and error corrections
This update corrects a bug in the appointment scheduling system's interval inversion function. The fix ensures accurate interval calculations across a range of scenarios, preventing incorrect scheduling and improving overall appointment management. New tests have been added to guarantee this fix.
Original PR description
The [commit](https://github.com/odoo/enterprise/commit/53450065be0c3ec9d648d4fd39ec3a9a912bd06c) introduced the method for inverting the interval inside the given limits. The method was failing for the following edge cases: ```python >>> invert_intervals([(1, 2), (4, 5)], 0, 10) result - [(2, 4), (5, 10)] expected - [(0, 1), (2, 4), (5, 10)]? >>> invert_intervals([(-2, -1)], 0, 10) result - [(0, 10)] expected - same >>> invert_intervals([(11, 12)], 0, 10) result - [] expected - [(0, 10)] >>> invert_intervals([(-1, 1), (2, 5), (8, 12)], 0, 10) result - [(1, 2), (5, 8)] expected - same >>> invert_intervals([(2, 5), (8, 12)], 0, 10) result - [(5, 8)] expected - [(0, 2), (5, 8)] >>> invert_intervals([(2, 5), (11, 12)], 0, 10) result - [] expected - [(0, 2), (5, 10)] ``` This commit fixes the function to correctly handle all the cases. The test cases are also added to test all the edge cases. Forward-Port-Of: odoo/enterprise#107112
This update resolves an issue where the image for a Text Cover block wasn't visible on mobile devices when toggled to be visible. The change adds a minimum height to the image element, ensuring it renders correctly below the 'lg' breakpoint. This improves the user experience for mobile viewers using Text Cover blocks.
Original PR description
Steps to reproduce: =================== 1. Add a Text Cover block to a page. 2. Optionally remove the text column so only the image remains. 3. Open the image column options and set "Visible on…
Steps to reproduce: =================== 1. Add a Text Cover block to a page. 2. Optionally remove the text column so only the image remains. 3. Open the image column options and set "Visible on Mobile". 4. Switch to mobile view. => Image column is empty. Root cause: ============ The image grid item is empty (background-image only) and relies on the parent `.o_grid_mode` being `display: grid` to be sized via `grid-area`. That `display: grid` rule is gated at `media-breakpoint-up(lg)` https://github.com/odoo/odoo/blob/d0424f2ffcf99ee59befe288150f1643b3fa0112/addons/web_editor/static/src/scss/web_editor.frontend.scss#L66 so below `lg` the item is a normal `display: block` element with no `col-*` class active (it has `g-col-lg-6 col-lg-6`, both `lg`-only) and no `g-height-*` CSS effect outside grid mode. The element therefore collapses to 0 height and the background image paints nothing. This regressed when the mobile-hidden breakpoint was extended from `md` to `lg`: - (See [1]) changed `d-none d-md-block` to `d-none d-lg-block o_snippet_mobile_invisible`. Before that, hiding only applied below `md`, where the image was rarely shown; afterwards the user can ask for it on mobile but gets an empty box. Fix: ==== Give the empty `oe_img_bg` grid item a `min-height` below `lg` so it has something to paint when the user makes it mobile-visible. [1]: https://github.com/odoo/odoo/commit/079575b8ba645e7ec564967698d76a94d18022c1 opw-6228392 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a bug where the DIN 5008 delivery slip layout wasn't properly hiding information. The fix involves a change to the CSS that prevents the 'information block' from being overridden, ensuring the DIN 5008 format correctly suppresses unwanted data on the delivery slip.
Original PR description
Steps to reproduce: ------------------- - Install `l10n_din5008` - Configure the document layout as DIN 5008 - Create and validate a delivery order - Print the delivery slip Issue: ------ The…
Steps to reproduce:
-------------------
- Install `l10n_din5008`
- Configure the document layout as DIN 5008
- Create and validate a delivery order
- Print the delivery slip
Issue:
------
The delivery slip still displays the information block (Order, Shipping Date, Total Weight, etc.),
although the DIN 5008 layout is expected to hide it.
Cause:
---------
The DIN 5008 layout made to hides the delivery slip `information` block: https://github.com/odoo/odoo/blob/674c748458e6e29715ad3763f267802d921dce55/addons/l10n_din5008/static/src/scss/report_din5008.scss#L73
Unfortunately, this behavior was broken in this [commit](https://github.com/odoo/odoo/commit/28c1cc6025005cd0937afbc452a722235cc5a38d):
The main purpose of this commit was to fix the alignment of the delivery slip.
As part of the fix, it added `class="report-wrapping-flexbox"`:
https://github.com/odoo/odoo/blob/674c748458e6e29715ad3763f267802d921dce55/addons/stock/report/report_deliveryslip.xml#L49
This prevents the information block from being hidden because of the CSS `!important` property:
https://github.com/odoo/odoo/blob/674c748458e6e29715ad3763f267802d921dce55/addons/web/static/src/webclient/actions/reports/bootstrap_review_report.scss#L59-L62
So when switching to the DIN 5008 format, it tries to hide the information block,
but the `!important` property prevents it from being hidden.
Solution:
------------
Backport this [commit](https://github.com/odoo/odoo/commit/8d588f8198d9057311304e596c009a0795ca6ec7):
In this commit, instead of targeting the `#information_block` itself,
it targets its children and hides all of them except `plan`.
As a result, all other children of the information block become hidden.
Since there is no `!important` rule on the children, they can be hidden successfully.
The information block then becomes empty and nothing is displayed.
<details>
<summary>Click here to see the results:</summary>
<p><strong>Before:</strong></p>
<div class="image-row">
<img src="https://github.com/user-attachments/assets/7529dec3-977b-4bee-8c0c-5ce8c09a09e9" />
</div>
<p><strong>After:</strong></p>
<div class="image-row">
<img src="https://github.com/user-attachments/assets/96ed3f8f-c874-4059-a19f-5ea3b380aba3" />
</div>
</details>
Why this fix:
--------------
These two different behaviors up to saas-18.4 and 19.0 led to a misunderstanding.
---
opw-6250072
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prA minor issue with the automated testing process (pylint) was identified and resolved. This ensures the quality and consistency of our French localization code, preventing potential errors before release. The fix improves the reliability of our testing framework.
Original PR description
```
FAIL: TestPyLint.test_pylint
Traceback (most recent call last):
File "/data/build/odoo/odoo/addons/test_lint/tests/test_pylint.py", line 109, in test_pylint
self.fail(f"pylint test failed:\n\n{r.stdout}\n{r.stderr}".strip())
~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: pylint test failed:
************* Module l10n_fr_pdp.tests.test_partner
function already defined line 134 (E0102) at odoo/addons/l10n_fr_pdp/tests/test_partner.py:152
--------------------------------------------------------------------
Your code has been rated at 10.00/10 (previous run: 10.00/10, +0.00)
```
runbot.build.error-939452This update resolves a bug preventing the correct processing of Peppol XML bills containing tax percentage information. The issue stemmed from an error in how the system interpreted the XML data, resulting in empty bills. This fix ensures accurate bill creation and import from UBL documents.
Original PR description
Steps to reproduce: - Upload a Peppol XML bill having the tax percent reported under "TaxTotal/TaxSubtotal/Percent" Issue: Bill will be created empty. The chatter will report the error ``` Error importing attachment 'bill.xml' (type=account.edi.xml.ubl_bis3): This specific error occurred during the import: float() argument must be a string or a real number, not 'lxml.etree._Element' ``` opw-6227637 [Ticket link](https://www.odoo.com/odoo/project/49/tasks/6227637)
This update resolves an issue where setting a non-numeric value for the 'next check number' in bank journals caused an error. The fix ensures the system validates the input to only allow numeric characters before attempting conversion, preventing the error and ensuring proper check number management.
Original PR description
Currently, an error occurs when a user sets a non-numeric value as the journal's next check number. **Steps to Reproduce:** - Install the `account_check_printing` module with demo data. - Go to…
Currently, an error occurs when a user sets a non-numeric value as the journal's next check number. **Steps to Reproduce:** - Install the `account_check_printing` module with demo data. - Go to `Invoicing` > `Configuration` > `Accounting` > `Journals`. - Open the `bank journal`. - In the `Outgoing Payments` tab > Enable `Manual Numbering`. - Set the `next check number` to a `non-numeric` value `(e.g. FA1234)` and `save`. `ValueError: invalid literal for int() with base 10: 'FA1234'` After [this commit], the next check number is converted to an integer without first validating that it contains only numeric characters [1]. Since the value can be non-numeric, converting it directly to an integer raises the error. This commit ensures that the next check number is converted to an integer only after verifying that it contains numeric characters only. [this commit]: https://github.com/odoo/odoo/commit/cc2004404462ecb523f7877569ce6a06b05341b4 [1]- https://github.com/odoo/odoo/blob/00dd75f345d7f5ddb04cecf52eca07e5a22c7d3c/addons/account_check_printing/models/account_journal.py#L57-L61 sentry-7498755988 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where time off allocation titles displayed excessively long decimal values. The change rounds the calculated duration to two decimal places, presenting a cleaner and more user-friendly display of hours. This ensures accurate and easily understandable information for time off requests.
Original PR description
Steps to reproduce: ------------------- 1. Install Time Off 2. Create an employee with a 38-hour working schedule (7.6h/day) 3. Create a time off type with request unit set to "Hours" 4. Create an…
Steps to reproduce: ------------------- 1. Install Time Off 2. Create an employee with a 38-hour working schedule (7.6h/day) 3. Create a time off type with request unit set to "Hours" 4. Create an allocation for this employee with a duration of 8 hours 5. Observe the allocation title displaying a long decimal value. (e.g., 7.999999999999999) Issue: ------ The `number_of_days` is calculated in `_compute_number_of_days` using: https://github.com/odoo/odoo/blob/ca01e606928a7704c6b2e4f430710f895be2653d/addons/hr_holidays/models/hr_leave_allocation.py#L261-L262 For an 8-hour request on a 7.6h/day schedule, this results in ~1.052631579 days. In `_get_title`, this value is multiplied back to show hours: https://github.com/odoo/odoo/blob/ca01e606928a7704c6b2e4f430710f895be2653d/addons/hr_holidays/models/hr_leave_allocation.py#L151 This multiplication leads to the long decimal values being displayed in the title. Solution: --------- Round the computed duration to two decimal places using `float_round`. **NOTE:** This issue is already fixed in saas-19.1 (commit 01d86a7). However, **no change** is required in the multi-allocation wizard, as the duration there directly uses user input and is not computed from working hours. opw-6091424 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where the ICP export generated inconsistent XML reports by using values from multiple company contexts. The change ensures a single, reliable company context is used, reusing precomputed values and preventing unintended overwrites. This results in more accurate and understandable ICP export data.
Original PR description
Description of the issue this commit addresses: The ICP export could mix values from different company contexts. In some cases, the main identifier and the fiscal entity division value did not come from the same source, which could create confusing or inconsistent XML output. --- Desired behavior after this commit is merged: This commit makes the ICP export use one consistent company context for identifier values, reuses precomputed values when available, and avoids overwriting them with unrelated defaults. --- task-6065382 Forward-Port-Of: odoo/enterprise#118998 Forward-Port-Of: odoo/enterprise#112995
This update resolves a problem where users were incorrectly denied access to create WhatsApp templates for events. The fix prevents users from creating new templates, ensuring proper access control and preventing the 'User does not have access' error. This improves the event communication process.
Original PR description
Issue: 1) User goes to Event.event Form -> communication tab -> add line 2) Select whatsapp -> type something -> create and edit -> create new template with any model event.registration -> save ( all the way including the event form) 3) reload page -> whatsapp event.mail displays "User does not have access to this record". Fix: add "'no_create_edit': True" to the associated field in the xml to block creation of new mail.templates opw-6037488
This update resolves an issue where the system incorrectly blocked sending invoices to 0225 Peppol EAS partners. Previously, this only worked when the French PDP module was installed. Now, it's enabled by default, ensuring compatibility with all Peppol partners, and resolving a problem with demo data installation.
Original PR description
Previously we blocked the 0225 peppol_eas when `l10n_fr_pdp` is not installed. But you should still be able to send to 0225 partners with just peppol. Since the PDP module is auto installed with the French localization and we block the 0225 EAS server side on the peppol (non-PDP) server it should be fine to just allow it for everyone. It also caused an issue when installing the demo data for the `hair_salon` industry in a French company on trial. opw-6268629
1 change
Resolved issues and error corrections
This update resolves an issue where FedEx was rejecting shipments due to the format of VAT numbers, specifically those used by countries like Switzerland. The change ensures that VAT numbers are properly sanitized to meet FedEx's requirements, preventing delivery errors and maintaining accurate data.
Original PR description
Backport of af0e834068a9ada2ad1d974c2dd6e75f876d68d9 Original PR: #109999 ----- Ticket: opw-6197750