Tuesday, June 2, 2026
13 changes · 18.0
Resolved issues and error corrections
The WIP report now displays accurate information when using analytic items tracked only with projects, preventing misleading demo data from appearing. This change ensures users see the correct report preview, improving data clarity and reducing potential confusion. This fix addresses a technical detail related to report editor previews.
Original PR description
Currently, when printing the WIP report, demo data is displayed if no product or references are provided on the analytic item. ## Steps to produce: - Install Manufacturing and Accounting - Go to…
Currently, when printing the WIP report, demo data is displayed if no product or references are provided on the analytic item. ## Steps to produce: - Install Manufacturing and Accounting - Go to settings and Enable Analytic Accounting - Search Analytic items and create a new Analytic Item by providing a description and amount. - Gear Icon > print and open the WIP report ## Observed Behavior: The report displays a product (laptop) with a demo reference. This becomes problematic when an analytic item is tracked only with a project, as it still causes product and reference data to appear on the analytic item. This can mislead the user. ## Root cause: After this [commit](https://github.com/odoo/odoo/commit/967ac550e38bab915180647dea6eccb2ae1b3b31), demo data values were added to the report to support report editor previews in the web studio. This helps users understand how the report will look while they are editing it. However, although an account analytic line is defined at [1], no values for fields such as products and references are specified on the form. As a result, the template falls back to the preview values provided. [1]- https://github.com/odoo/odoo/blob/d66bb0d7b550b11876dbc7b9d87f5b2adc17dd74/addons/mrp_account/report/report_mrp_templates.xml#L32-L53 ## Solution: Using `data-oe-demo` instead of removing the fallback data appears to be the best approach, as it allows the report editor to continue using demo values for the report preview, as shown at [2] **Before:** <img width="871" height="340" alt="image" src="https://github.com/user-attachments/assets/91897dbd-65d8-4f70-8f22-ea38b42ba28d" /> **After:** <img width="815" height="380" alt="image" src="https://github.com/user-attachments/assets/ffcf509b-f534-47a8-be1d-53a798995443" /> [2]: https://github.com/odoo/enterprise/blob/a739c6c03c6629bad80f3fe61b1035ce156d59c6/web_studio/static/src/client_action/report_editor/report_iframe.scss#L65-L75 opw-6151563 Forward-Port-Of: odoo/odoo#262517
This update resolves issues encountered during Odoo's demo mode, specifically bypassing unnecessary authentication steps and preventing the forced use of two-factor authentication. Additionally, the system now correctly handles document sending for both Peppol Users and PDPs, ensuring accurate functionality in 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
This update fixes an issue where the duration of calendar events created through dragging and the quick-create popover wasn't accurately reflected in the full event form. Now, the duration displayed in the full form correctly matches the user's intended event length after modifying the end time.
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
This update resolves a bug where color selections within the HTML editor's mobile interface weren't consistently applying colors after using the color picker. The fix adjusts the selection offset to prevent browser normalization, ensuring colors are correctly applied to collapsed selections. This improves the user experience for color formatting.
Original PR description
Steps to Reproduce: - Apply color on a collapsed selection in mobile - Type some text - Change color from the color picker Description of the issue: - The color picker closes, but the selected color is not applied. Cause: - The color was being applied correctly, but the selection was positioned at offset 0 of the newly created font node. As a result, the browser normalized the selection back to the previous font node, making it appear as though the color was not applied. Solution: - When applying color on a collapsed selection, set the selection offset to 1 instead of 0. This prevents browser normalization and keeps the cursor inside the newly created font tag, ensuring the color is applied correctly. task-6201171
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. The change prevents warnings when a company isn't using the Italian EDI method, even if the partner's settings indicate it should be. This improves the user experience and reduces unnecessary alerts.
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
This update clarifies a confusing column in the HR attendance reports. The column name was previously misleading, indicating expected hours instead of regular working hours. Renaming it to 'regular hours' improves report readability and accuracy for HR staff.
Original PR description
The column name "Expected Hours" and "Theoretical Hours" is confusing since it doesn't show the hours that the employee is supposed to work according to their contract, just the number of hours that are not considered overtime. This commit renames the column to better reflect the measure that is shown. task-6123642 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where the year calculation for weeks overlapping between years was incorrect, leading to unexpected week number resets. The change ensures consistent year and week number tracking, particularly at the end of a year, preventing errors and maintaining accurate date calculations. This improves the reliability of date-based reporting and scheduling.
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
This update corrects a technical issue within the accounting module that could cause errors when attachments were missing. The fix ensures the system handles empty attachments gracefully, preventing potential crashes and improving stability. This change primarily impacts the account module.
Original PR description
In https://github.com/odoo/odoo/commit/b86104514acf631003812ba8d120cc7b69d7da95 guess_mimetype is given a string fallback in case of no attachment content. However the fallback type is wrong and may lead to a traceback. no-opw Forward-Port-Of: odoo/odoo#267188
This update corrects a bug in the account reports module that caused the growth comparison percentage to incorrectly change when switching between different time periods. The original implementation assumed a specific period order, leading to inconsistent calculations. This fix ensures accurate growth comparisons regardless of the selected period order.
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.
This update resolves an issue where the system incorrectly imported invoice quantities from UBL files. Specifically, when the UBL file indicated a zero quantity, the system was importing a quantity of '1'. This change ensures accurate quantity data is imported from UBL invoices, improving data integrity and reporting.
Original PR description
…ase_quantity equal to zero **STEP TO REPRODUCE** 1. Import the 2fact ubl from the bugfix ticket. 2. Notice some line are imported with quantity = 1, but the quantity invoiced in the ubl is 0. opw-6260558
This update resolves a problem with the partner merge wizard in Odoo's French (pdp) module. The previous method of using 'company_dependent' caused errors. This change utilizes 'depends_context' for accurate calculations, ensuring the partner merge process functions correctly.
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
This update resolves a problem where users accessing archived documents through specific methods (like widgets or direct URLs) would incorrectly display a 'not found' message. This fix ensures that archived documents are correctly accessed, improving the user experience. It's a follow-up to previous related tasks.
Original PR description
When a user tries to access an archived document via * a many2one widget * `/odoo/documents.document/<id>` * a discuss notification they end up in "All" with a toast specifying that the document was not found. Follow-up of Task-6068437 (follow up of Task-5386466). Task-6214488
This update resolves an issue where an error was 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, aligning with how intrastat codes are properly stored on product variants. This improves data accuracy and prevents unnecessary errors.
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