Daily updates from Odoo
Monday, March 16, 2026
76 changes
14 changes
Resolved issues and error corrections
This update fixes a technical issue within the Odoo Studio's form editor that previously caused crashes when interacting with certain fields. The change ensures the sidebar correctly displays information, preventing errors and improving the user experience. This resolves a bug impacting form editing functionality.
Original PR description
In studio, form editor: click on a field and check the sidebr is correct Click on another field, one that has the widget many2many_tags. Before this commit, there was a crash because the internals of the sidebar were computed with the wrong props (the old ones instead of the new ones) After this commit, there is no crash opw-6004776 Forward-Port-Of: odoo/enterprise#110391 Forward-Port-Of: odoo/enterprise#110284
This update fixes a technical issue related to email field requirements in the marketing automation module. The system now correctly determines if an email body is required based on its content, ensuring data integrity. Additionally, a minor adjustment was made to tours to ensure form views are properly cleared during automated testing.
Original PR description
Prior to this commit, `body_html` was hard-coded as a dependency of the `mass_mailing_html_field`, and that dependency lacked the `required` attribute, which should depend on the value of `body_arch`. The dependency is now added in the related views, and the field is now generic. As HtmlField now mark the record `dirty` `onChange`, some tours should ensure that the form view is properly discarded before finishing. task-5976348 Forward-Port-Of: odoo/enterprise#109874 Forward-Port-Of: odoo/enterprise#109091
This update resolves a bug where icons within the HTML editor weren't correctly padded with special characters (feffs). This ensured icons displayed properly after content was added or the page was reloaded. The fix improves the visual consistency of the editor.
Original PR description
Problem: When content is added to the editor, icons are not surrounded by `feff`s. Cause: The selector used to pad elements with `feff`s relies on `o-paragraph`, which is added during normalization.…
Problem: When content is added to the editor, icons are not surrounded by `feff`s. Cause: The selector used to pad elements with `feff`s relies on `o-paragraph`, which is added during normalization. However, `BaseContainerPlugin.normalize_handlers` runs last, so when `FeffPlugin.normalize_handlers` executes, it cannot find icons through `selectors_for_feff_providers` because the expected paragraph-related parent is not yet in place. Solution: Execute `FeffPlugin.normalize_handlers` immediately after `BaseContainerPlugin.normalize_handlers`, ensuring the DOM structure is ready before attempting to add surrounding `feff`s. Steps to reproduce: - Add an icon. - Reload the page. - Do not make any changes (so normalization is not triggered again). - Inspect the icon and observe that it does not have surrounding `feff`s. task-5960097 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252278 Forward-Port-Of: odoo/odoo#250855
This update fixes a problem where temporary files used during report generation weren't being properly deleted after tests, leading to potential disk space issues. The fix ensures these files are cleaned up immediately, preventing accumulation and improving system stability. This resolves a minor technical issue with no direct impact on users.
Original PR description
Investigated after finding `/tmp/report.*` left over after running tests. #186547 left some temporal holes in the cleanup which are apparently sufficient to not correctly clean the files in some cases? Since `mkstemp` already creates the files, don't wait to have written stuff inside to record the file for deletion, do it immediately *then* write content to the file. An even better solution would be to use `NamedTemporaryFile(delete_on_close=False)`, however that's only available from 3.12, and it does not log deletion errors (although I'm not convinced that's useful in the first place). Forward-Port-Of: odoo/odoo#253816 Forward-Port-Of: odoo/odoo#253053
This update fixes an inconsistency in the website editor's parallax preview animation across different browsers (Firefox and Chrome). The change ensures a more reliable and predictable preview experience by using a standard root height measurement instead of a browser-specific one.
Original PR description
Steps to reproduce: - Open the website editor. - Open the snippet dialog. - Scroll through a parallax snippet preview in Firefox and Chrome. => The preview animation does not move the same way. Before this commit, the parallax preview used `body.clientHeight` inside the scaled snippet preview iframe. Firefox and Chrome can return different values there, so the preview animation was inconsistent. After this commit, the preview reads `document.documentElement.clientHeight` instead, which gives a stable iframe viewport height across browsers. Forward-Port-Of: odoo/odoo#253541
This update fixes a display issue where the mega menu in mobile view was taking up too much space when the menu size was set to 'Narrow'. The change ensures the mega menu's width is correctly controlled, preventing it from overflowing the mobile navigation bar. This improves the user experience on smaller screens.
Original PR description
The property "max-width" of the mega menu in mobile view was set with the class o_mega_menu_is_offcanvas of its ancestor. However, when the user set the mega menu template size to "Narrow", new CSS rules were added to change the mega menu size based on the screen size. The first rule was overridden, resulting in the mega menu being larger than the mobile navbar width. This commit sets the property "max-width" as "important" to prevent this issue from occurring. task-5972284 Forward-Port-Of: odoo/odoo#250690
This update resolves an issue where changing the 'Kitchen Note' on a food item after a quantity update would cause an error. The fix ensures that the note field can be updated successfully without triggering a technical problem, improving the reliability of the POS system for restaurant operations.
Original PR description
**Steps to Reproduce:** - Install `pos_restaurant_preparation_display`. - Open Register for POS "**Restaurant**" Shop. - Choose table > select food-item > send the order. - Update food-item quantity > send the updated order. - Update food-item '**Kitchen Note**' > send the note. **Error:** `TypeError - 'NoneType' object is not subscriptable` **Cause:** When the food quantity is updated, a new preparation entry is created for the increased quantity. During the first iteration, the display and order quantities are already merged correctly. However, in a subsequent iteration, the original key no longer exists in `quantity_data`. As a result, accessing a None value leads to a traceback. **Fix:** This commit skips the merge step when the original quantity entry has already been merged. sentry-7197024946 Forward-Port-Of: odoo/enterprise#110184 Forward-Port-Of: odoo/enterprise#104889
This update ensures that the employee assigned to a Point of Sale (PoS) configuration is correctly linked to the PoS company. Previously, users without HR access could encounter access errors if the assigned employee was from a different company. The fix automatically filters employees to match the PoS company or defaults to a user in the 'pos_manager' group.
Original PR description
When writing to a PoS config, it will automatically set an `advanced_employee_ids` if none is set. But it will take any employee that is part of `point_of_sale.group_pos_manager`. If the employee…
When writing to a PoS config, it will automatically set an `advanced_employee_ids` if none is set. But it will take any employee that is part of `point_of_sale.group_pos_manager`. If the employee selected is not part of the same company as the PoS config, and the current user doesn't have HR employee access it will trigger an ir.rule that block the user from opening the settings. Steps to reproduce: ------------------- * Create a new company * Create a new user that only have access to this company and no HR access * Create a PoS in the new company * Login as the new user * Try to open the settings > Observation: You will get an access error because the employee set in `advanced_employee_ids` is from the other company Why the fix: ------------ We make sure that when automatically setting the advanced_employee_ids we filter out the ones that are not from the correct company. If no employee exist that satisfies the requirements, we take a user from the `group_pos_manager` and create an employee for him. opw-5885417 Forward-Port-Of: odoo/odoo#253687 Forward-Port-Of: odoo/odoo#252402
This update resolves an issue where a specific cash move type in the German Point of Sale (POS) module was incorrectly formatted, leading to an error with the Fiskaly accounting system. The fix ensures the correct type casing is used, preventing the error and allowing proper cash move processing.
Original PR description
When creating a cash move of type "Cash Supplement", the type sent was "Zuschussecht" instead of "ZuschussEcht", which caused is not an allowed type. Steps to reproduce: ------------------- * Setup a PoS with a TSS for a German localization * Start a session and open the cash control popup * Create a cash move of type "Cash Supplement" * Close the session > Observation: You get an error from Fiskaly that the type is not allowed Why the fix: ------------ When doing `.capitalize()` on a string it would make the first letter uppercase and the rest lowercase. In this case "ZuschussEcht" would become "Zuschussecht", which is not the correct type expected by Fiskaly We now keep the original casing for all the type. opw-5462364 Forward-Port-Of: odoo/enterprise#110270 Forward-Port-Of: odoo/enterprise#109235
This update resolves an issue where users without HR officer permissions would encounter an error when trying to open user forms. The team removed unnecessary PIN information from the main user view, streamlining the process for authorized users to manage user accounts. This ensures a smoother experience for all users with appropriate access.
Original PR description
If a person having rights to edit users is not HR officer, he gets a traceback when he tries to open the user form. As the information of PIN is not really related to the user, we left it on the employee and the "Preference" view, but remove it from the main user view --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251787
A test was failing due to a mismatch between the user's language setting (French) and the content of a tour designed for English. This commit resolves the issue, ensuring the test now passes correctly and preventing potential display problems in the web studio.
Original PR description
Before this commit, a test set the language of the user to French and then opened the browser with that user and that language. The tour in question, written for English failed. After this commit, the tour doesn't fail runbot-error-241983
This update fixes a minor issue within the Point of Sale course preparation tour. By adding specific steps, the tour now reliably triggers the necessary courses, ensuring users are properly guided through the setup process. This improves the onboarding experience and reduces potential confusion.
Original PR description
In this commit: --- - Add steps in the tour to ensure courses are correctly triggered. runbot-241931 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a confusing issue where draft payslip PDFs remained in the foreground after payrun validation. The change ensures payslips are correctly marked for PDF generation, and updates the default attachment to resolve the display problem. This improves clarity for users receiving payslip reports.
Original PR description
When creating a payrun and using the Test Print button, the pdfs with the yellow banner saying that the payslip is still draft are generated correctly. When validating the payrun a cron runs to generate the real pdfs. In 19.2 there is a preliminary problem (fixed here) where the payslips are not marked for pdf creation and therefore are not taken by the cron (in master they are correctly marked for it). After that, the pdfs are correctly computed but the pdf in the foreground remains the draft one, generating confusion. With this PR we also change the default attachment when we generate de final pdf, solving the problem. Task: 6023186
This update resolves a technical limitation in the Odoo Report Editor, preventing users from applying properties to fields selected within the /field command. Previously, this functionality was inconsistent, leading to issues with report customization. This change ensures proper field selection and improves report editing capabilities.
Original PR description
Properties are not supported in ir.qweb but only as t-out, while t-field doesn't support them. For this reason and the fact that properties have a path the model field selector barely handles we do not allow those field to be selected in the /field command task-5999790 Forward-Port-Of: odoo/enterprise#110409 Forward-Port-Of: odoo/enterprise#109486
11 changes
Resolved issues and error corrections
This update resolves a failing test within the Odoo Enterprise platform's order processing system. The issue stemmed from a new requirement for a kitchen printer, which wasn't available in the test environment, causing disruptions in the order flow. This fix ensures the test now runs correctly.
Original PR description
This commit fixes the failing `test_platform_order_flow` test, specifically within the `test_platform_order_reject_flow` tour at the `.ticket-screen` step. Explanation: The root cause of this issue is that the system is now expecting a kitchen printer to be present to process the order flow. However, the unit test environment does not have a kitchen printer configured, which causes the flow to halt or behave unexpectedly when the system tries to interact with it. Reference: Breaking PR: odoo/odoo#226447 build_error-241246 Forward-Port-Of: odoo/enterprise#110249
A test was failing due to an issue with how the system calculates dates and time zones. This fix corrects a calculation error that resulted in an incorrect date being generated, ensuring the planning module's tests run successfully. This resolves a potential disruption to the planning functionality.
Original PR description
__ ## Error description The test fails when it is launched at 23h. We obtain an assertion error: `AssertionError: datetime.datetime(2026, 2, 26, 11, 0) != datetime.datetime(2026, 2, 25, 11, 0)` ##…
__ ## Error description The test fails when it is launched at 23h. We obtain an assertion error: `AssertionError: datetime.datetime(2026, 2, 26, 11, 0) != datetime.datetime(2026, 2, 25, 11, 0)` ## Origin of the issue In the `_default_start_datetime()` method of planning, we return `return datetime.combine(fields.Date.context_today(self), time.min)`. So, we call context_today. which is implemented this way: https://github.com/odoo/odoo/blob/f3ec2aa4514c03874aae96ae975e2617e8260c72/odoo/orm/fields_temporal.py#L154-L158 Let's say the hour of the test is 23h50 in GMT+0. The slot will be created at 23h50 in GMT+0. But if the time zone of the environment is set at GMT+1, at the moment of the `_compute_datetime`, we will call this piece of code, where we will translate 23h50 to GMT+1, we will obtain 00h50, then only return the day, which offsets the result of one day in the future. X-original-commit: d91c53869842f65a60088ffa101f67404af6e58e note: backport of https://github.com/odoo/enterprise/pull/108891 Forward-Port-Of: odoo/enterprise#110126
This update resolves an issue where users couldn't type spaces into 'Add to cart' buttons within the website editor. The fix involves a technical adjustment to the button's structure, ensuring spaces are correctly inserted as intended. This improves the user experience when customizing website product pages.
Original PR description
Problem: After https://github.com/odoo/odoo/commit/e809b492c1b138c1af7bb1d4aa61b39d87686df9 typing spaces inside an "Add to cart" button label in the website editor triggers the button click instead…
Problem: After https://github.com/odoo/odoo/commit/e809b492c1b138c1af7bb1d4aa61b39d87686df9 typing spaces inside an "Add to cart" button label in the website editor triggers the button click instead of inserting a space character. Cause: Browsers natively intercept the space key on `button[contenteditable="true"]` elements and fire a click event instead of inserting the character, making it impossible to type spaces in the button label. Solution: Introduce an `EditableButtonPlugin` that moves the `contenteditable` attribute from the button up to a wrapping `<span>`. This preserves full text editing capability (including spaces) without triggering the button's click handler. Steps to reproduce: * Go to a product page on the website. * Open the editor. * Try to add a space in the "Add to cart" button label. * Observe that the button is triggered instead of inserting a space. opw-5994828 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a bug that caused product imports to create redundant records when importing multiple products with the same attribute values. By using a 'set' instead of a 'list', the system now ensures unique values are created, preventing inconsistencies and maintaining product variant usability. This improves import reliability and data accuracy.
Original PR description
Product imports were creating redundant `product.attribute.value` records because batch values were stored in a list without uniqueness checks. This fix ensures that: - Unique values are identified before creation. - Product variants remain usable and consistent. Issue: 5918366 Fixes the issue where importing 200 products with the same attribute value created 200 identical records.
This update fixes a bug where employee skills weren't automatically added to appraisals created by the system's automated scheduling process. The fix ensures that all appraisals, regardless of their creation method, correctly display the employee's skills in the Skills tab. This improves data accuracy and usability.
Original PR description
Steps to reproduce: ------------------------------------- 1. Install `hr_appraisal_skills` module 2. Create a new employee and assign at least one skill to the employee 3. Set the Next Appraisal Date…
Steps to reproduce: ------------------------------------- 1. Install `hr_appraisal_skills` module 2. Create a new employee and assign at least one skill to the employee 3. Set the Next Appraisal Date to today 4. Go to Scheduled Actions > Appraisal: Run employee appraisal > Run Manually 5. Open the newly created appraisal for the employee Observation: ------------------------------------- In the Skills tab, the employee's skills are not populated even though the appraisal is already in the confirmed stage Issue: ------------------------------------- When the cron `_run_employee_appraisal_plans` creates an appraisal, it is created directly in `pending` state via `create()`. The skill-copying logic only lived in the `write()` override, which triggers on state transitions from 'new' to 'pending'. Since `create()` bypasses `write()`, Employee skills were never copied to cron-created appraisals https://github.com/odoo/enterprise/blob/451dce92a087086fc3d5d5f610626312f32bcd13/hr_appraisal_skills/models/hr_skills.py#L12-L15 Solution: ------------------------------------- Add a `create()` override to call `_copy_skills_when_confirmed` when an appraisal is created directly in the `pending` state, ensuring employee skills are properly copied. opw-5491433 Forward-Port-Of: odoo/enterprise#110414 Forward-Port-Of: odoo/enterprise#107760
This update resolves an issue where parallax preview animations appeared differently in Firefox and Chrome due to inconsistent iframe height measurements. The fix now uses a standard root height measurement, ensuring a consistent and reliable preview experience across all browsers. This improves the overall user experience for website editors.
Original PR description
Steps to reproduce: - Open the website editor. - Open the snippet dialog. - Scroll through a parallax snippet preview in Firefox and Chrome. => The preview animation does not move the same way. Before this commit, the parallax preview used `body.clientHeight` inside the scaled snippet preview iframe. Firefox and Chrome can return different values there, so the preview animation was inconsistent. After this commit, the preview reads `document.documentElement.clientHeight` instead, which gives a stable iframe viewport height across browsers. Forward-Port-Of: odoo/odoo#253541
This update fixes a display issue where the mega menu in mobile view was taking up too much space when the menu size was set to 'Narrow'. The change ensures the mega menu's maximum width is correctly defined, preventing it from overflowing the mobile navigation bar. This improves the user experience on smaller screens.
Original PR description
The property "max-width" of the mega menu in mobile view was set with the class o_mega_menu_is_offcanvas of its ancestor. However, when the user set the mega menu template size to "Narrow", new CSS rules were added to change the mega menu size based on the screen size. The first rule was overridden, resulting in the mega menu being larger than the mobile navbar width. This commit sets the property "max-width" as "important" to prevent this issue from occurring. task-5972284 Forward-Port-Of: odoo/odoo#250690
This update resolves an issue where users with HR access rights would receive an error when trying to view other users' profiles. The change restricted access to the 'pin' field, which was previously incorrectly exposed. This ensures HR staff can properly access user information.
Original PR description
The field `res_users.pin` is restricted to members of `hr.group_hr_user` but is added to the form view, so if a user with HR access rights tries to view another user, it will trigger an access error:…
The field `res_users.pin` is restricted to members of `hr.group_hr_user` but is added to the form view, so if a user with HR access rights tries to view another user, it will trigger an access error: ``` odoo.exceptions.AccessError: You do not have enough rights to access the field "pin" on Employee (hr.employee). Please contact your system administrator. ``` To reproduce: - With `hr` installed, remove its access rights from the admin and try to view another user. This error is related to recent changes[^1] in the access of employee fields, it might be possible to have a different approach to this error. It will break while trying to access the employee field for which the user doesn't have access: https://github.com/odoo/odoo/blob/012f510e70d7d0afd226e4198b2e1759db3ca18d/addons/hr/models/res_users.py#L29-L36 In earlier versions, the field was not accessed directly. It was just automatically hidden from the view if the user didn't have the right group. [^1]:https://github.com/odoo/odoo/commit/012f510e70d7d0afd226e4198b2e1759db3ca18d
This update resolves a problem where the website's promotional tour occasionally failed to run correctly. The fix was identified through automated testing and ensures the tour consistently functions as intended for users. This improves the user experience and prevents potential frustration.
Original PR description
See https://runbot.odoo.com/odoo/runbot.build.error/234533
This update clarifies error messages for declined payments related to international vendors. Previously, users saw a generic "Country not allowed" message when payments were refused due to vendor location discrepancies. Now, the system incorporates payment data to provide more specific and helpful error messages, improving the user experience.
Original PR description
A company in belgium creates a card, it's "allowed countries" is set to Belgium by default. If said card is used to pay online on a website ending with .be, it is understandable that the user believes the vendor to be located in Belgium If it is not the case (the vendor is actually in Luxembourg), the payment is refused but the message on the refused expense is unclear "Country not allowed" The change adds the data received to make the decision in the error message task: 5478443 Forward-Port-Of: odoo/enterprise#103974
A crash in the DIN 5008 report layout preview was resolved. The issue stemmed from an attempt to access company data within the QWeb template that wasn't always present. The fix adds a check to ensure the company record exists before attempting to retrieve its name, preventing the error.
Original PR description
**Steps to reproduce** - Settings -> Configure Document Layout - Set layout to DIN 5008, save - Click Preview Document **Error** `MissingError: Record does not exist or has been deleted.(Record: res.company(X,), User: 2)` Raised in l10n_din5008.external_layout_din5008 because of this line: `<span t-elif="'name' in o" t-field="o.name"/>` **Cause** The "Preview Document" button renders web.preview_externalreport, which passes a res.company record as the QWeb variable o. When the template then tried to render t-field="o.name" (the title line), where o is a missing res.company(2) (not in the database), QWeb raised the MissingError. **Fix** Guard the title block with `if o and o.exists()` to check if the record exists, so it's safe to access `o.name`. opw-5951003 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
2 changes
Resolved issues and error corrections
This update fixes an issue where cancelled vendor bills were incorrectly included in the Sweden accounting SIE export file. The fix ensures that cancelled transactions are properly excluded, aligning the export data with the general ledger. This prevents inaccurate reporting and maintains data integrity.
Original PR description
Steps to reproduce: - Install l10n_se (Sweden - Accounting). - Create a Vendor Bill with a line using Account 4000 (Cost of goods) for any amount (e.g., 10,000 SEK). - Confirm/Post the bill. - Cancel the bill. - Go to Accounting > Reporting > SIE Export and generate the export for the current year. - Open the downloaded .se file and locate the #RES line for Account 4000. Expected: The balance should be 0.00 (cancelled entries must be ignored, matching the GL). Actual: The cancelled amount (10,000) is incorrectly summed into the exported balance. opw-5901999 Forward-Port-Of: odoo/enterprise#108767
This update resolves issues with the formatting of Dutch SBR and ICP reports, specifically correcting VAT tag values and date formats within the exported XML files. A cleanup helper has been added to improve the readability of these files for internal use.
Original PR description
Descriptions of the issues this commit addresses: The xbrli:identifier tags in the exported sbr and sbr icp files are wrong. They should always contain the company's vat without country code . The DateTimeCreation tag currently shows a date in a wrong format. It it YYYYMMDDhhmm but should be YYYY-MM-DDThh:mm:ss. Also the outputted xml is weirdly indented with many whitespaces and it makes it hard to read for no reason. --- Desired behavior after the commit is merged: This commit changes the values in the exported file to address those issues and adds the use of a cleanup helper to make the file human readable. --- task-5998939 Forward-Port-Of: odoo/enterprise#109359
8 changes
Resolved issues and error corrections
This update resolves a limitation in the Odoo Enterprise system by enabling users to select 'Other Expenses' as a valid expense account option when creating loans. Previously, this option was restricted, which could have prevented accurate tracking of certain loan expenses. This change improves the flexibility and accuracy of loan expense reporting.
Original PR description
Allow accounts with the "Other Expenses" type to be selected in the Expense Account field of Loans. task-5946452
This update prevents users from copying data directly from the public Odoo spreadsheet. Previously, users could easily copy and paste information, which posed a risk to data integrity and consistency. This change ensures that data within the spreadsheet remains controlled and accurate.
Original PR description
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 addresses a persistent issue where temporary report files were accumulating on systems due to a misconfigured test. The root cause was a test that didn't properly clean up these files, leading to unnecessary storage usage. This fix ensures reports are cleaned up correctly during testing and operation.
Original PR description
Followup to #253053 which assumed it was some sort of race in the report code which would sometimes fail to cleanup the temp files, but after hitting a test failure in #253816 the true culprit was revealed: it was the test #186547 added all along and I didn't even think to run it! Because `test_report_error_cleanup` mocks the `os.unlink` call the `os.unlink` call never happens during that test, so none of the temporary files get deleted, and this is what added a full set of report files to my /tmp every day as I'd run the entire test suite in the morning. To be clear the race was still there and resolving it was reasonable it, but that was not the cause of the leftover temporary files, or if so extremely rarely. Forward-Port-Of: odoo/odoo#253853
This update fixes a persistent problem where Chrome was creating unnecessary temporary files, leading to potential performance issues. By directing Chrome to use its temporary directory as its data directory and then cleaning up this directory during testing, we've eliminated this file clutter.
Original PR description
It's unclear since when or under what configuration exactly, but Chrome(ium?) seems prone to creating directories called `org.chromium.Chromium.*` (or some variant thereof) in the temp dir (some people report them to be prefixed by a `.`) and never clean them. By telling chromium that its tempdir is its data dir, it creates its litter in there, and we remove the entire thing during cleanup, solving the littering. Forward-Port-Of: odoo/odoo#253350
This update resolves an issue where adding attributes to archived product templates caused errors. The fix ensures all variants (active and archived) are considered, preventing template deletion and maintaining archived product options when a template is archived.
Original PR description
When adding attributes to an archived product template, an error was raised because the template was incorrectly deleted. This happened because variant counting only considered active variants. Now counts all variants (active and archived) to prevent template deletion, and filters variants before activation to keep them archived when their template is archived. @qrtl QT6449 Forward-Port-Of: odoo/odoo#252927
This update fixes an issue where follow-up emails were incorrectly sending a generic attachment instead of the actual invoice PDF. Now, the system automatically sends the correct invoice PDF, ensuring users receive the accurate documentation for their invoices. This improves the clarity and accuracy of invoice follow-up communications.
Original PR description
Before, the followup emails used the Invoice's main attachment. This is not correct because a user might have uploaded an arb PDF. Only the actual PDF should be sent. Use `invoice_pdf_report_id` instead of `message_main_attachment_id`. opw-5126420 Forward-Port-Of: odoo/enterprise#98820
This update fixes a usability issue on mobile devices when creating new loans. Previously, a button was hidden and difficult to access, requiring scrolling. The fix ensures a smoother, more intuitive experience for users creating loans on their smartphones or tablets.
Original PR description
Forward-Port-Of: odoo/enterprise#110120
Previously, when users uploaded multiple files to a WhatsApp Discuss channel, only the first file was delivered. This update corrects this issue by ensuring that all uploaded files are sent to the recipient. The fix prevents data loss and improves the reliability of file sharing within WhatsApp.
Original PR description
Multiple attachments uploaded simultaneously to a WhatsApp Discuss channel result in only the first being delivered to the recipient. ### Steps to reproduce 1. Drag and drop multiple files into a…
Multiple attachments uploaded simultaneously to a WhatsApp Discuss channel result in only the first being delivered to the recipient. ### Steps to reproduce 1. Drag and drop multiple files into a WhatsApp Discuss channel. 2. Send the message. -> Odoo shows all files, but only the first reaches the destination. ### Cause WhatsApp's API permits only one media object per message. Odoo's "Composer" enforces this by blocking uploads if an attachment is already present. However, it only evaluates the *current* state; dropping multiple files into an empty composer passes the check because the count is zero. On the server, the WhatsApp backend (constrained by the API) is hardcoded to send only the first attachment, silently discarding the rest. ### Fix Updated frontend validation to inspect the incoming file list during drop and paste actions. The process is now blocked if the total of existing plus incoming files exceeds one, ensuring the user is notified and preventing silent data loss. opw-5889035 Forward-Port-Of: odoo/enterprise#107424
6 changes
Resolved issues and error corrections
This update ensures that follow-up emails for invoices send the correct PDF attachment. Previously, emails used the main attachment, which could be any uploaded PDF. Now, the system uses the invoice's specific PDF report to guarantee accurate invoice information is sent to customers.
Original PR description
Before, the followup emails used the Invoice's main attachment. This is not correct because a user might have uploaded an arb PDF. Only the actual PDF should be sent. Use `invoice_pdf_report_id` instead of `message_main_attachment_id`. opw-5126420 Forward-Port-Of: odoo/enterprise#98820
This update resolves a recurring issue where the Italian POS printer would generate errors when the system was offline. The fix adds a safety mechanism to gracefully handle network disruptions during receipt printing, preventing errors and improving the user experience for Italian retail customers. It ensures the POS system functions correctly even without an internet connection.
Original PR description
When loosing internet connexion a lot of tracebacks appear is the pos if we use the italian fiscal printer. Steps to reproduce: ------------------- * Setup italian fiscal printer for a shop * Open shop * Turn wi-fi off * Add items to cart * Go to payment screen > Traceback * Add a payment and validate > Traceback Why the fix: ------------ Don't try to reach the printer if we're offline regarding the price to pay. We add a try catch block around the call for printing the receipt. If the try block fails when the network is offline we assume it's just because of the offline mode. If it failed while online we raise the error. opw-5432090 Forward-Port-Of: odoo/enterprise#105515
This update fixes an issue where cancelled vendor bills were incorrectly included in the Sweden (l10n_se) SIE export file. The fix ensures that cancelled transactions are excluded, aligning the export with the general ledger and providing accurate financial reporting. This prevents discrepancies in reporting.
Original PR description
Steps to reproduce: - Install l10n_se (Sweden - Accounting). - Create a Vendor Bill with a line using Account 4000 (Cost of goods) for any amount (e.g., 10,000 SEK). - Confirm/Post the bill. - Cancel the bill. - Go to Accounting > Reporting > SIE Export and generate the export for the current year. - Open the downloaded .se file and locate the #RES line for Account 4000. Expected: The balance should be 0.00 (cancelled entries must be ignored, matching the GL). Actual: The cancelled amount (10,000) is incorrectly summed into the exported balance. opw-5901999 Forward-Port-Of: odoo/enterprise#108767
This update fixes a usability issue on mobile devices where a key button for loan calculations was hidden within a dropdown. The change ensures the button is always accessible, streamlining the loan creation process for mobile users. This improves the overall user experience and efficiency.
Original PR description
Forward-Port-Of: odoo/enterprise#110120
This update resolves an issue where GS1 barcode filtering would fail due to an error when a barcode was interpreted as a date. The fix prevents this error from blocking the filtering process, ensuring that products can be correctly identified and filtered by their barcodes. This improves the reliability of internal transfer operations.
Original PR description
Steps to reproduce: - Activate the GS1 nomenclature - Create a product "P1" with the barcode: 15099590225865 - Create an internal transfer with one unit of P1 - Go to Barcode > Operations > Internal…
Steps to reproduce: - Activate the GS1 nomenclature - Create a product "P1" with the barcode: 15099590225865 - Create an internal transfer with one unit of P1 - Go to Barcode > Operations > Internal Transfers - Scan the barcode: 15099590225865 to filter transfers by this product barcode Problem: An validation error is raised: A ValidationError is raised: "A GS1 barcode nomenclature pattern was matched. However, the barcode failed to be converted to a valid date." Explanation: GS1 barcodes must follow a strict nomenclature based on well-defined rules. For example, a GS1 product barcode should start with the Application Identifier 01 followed by 14 digits. The GS1 parser processes the barcode rule by rule and applies the first matching rule. In this case, the barcode 15099590483921 is interpreted as a date because it starts with "15", which corresponds to a GS1 Application Identifier for a date. As a result, the parser attempts to convert the first six digits into a date and raises a ValidationError. Solution: Catch the ValidationError raised during GS1 date parsing in filter_on_barcode and explicitly reset parsed_results to False, allowing the normal filter on product resolution logic to continue. This prevents GS1 parsing errors from blocking valid barcodes and ensures that product is correctly filtered opw-5929064 Forward-Port-Of: odoo/enterprise#110636
This update resolves issues with the formatting of Dutch SBR and ICP export files, specifically correcting incorrect VAT identifiers and date formats. A cleanup process has been added to improve the readability of the XML files, ensuring accurate reporting for Dutch tax compliance.
Original PR description
Descriptions of the issues this commit addresses: The xbrli:identifier tags in the exported sbr and sbr icp files are wrong. They should always contain the company's vat without country code . The DateTimeCreation tag currently shows a date in a wrong format. It it YYYYMMDDhhmm but should be YYYY-MM-DDThh:mm:ss. Also the outputted xml is weirdly indented with many whitespaces and it makes it hard to read for no reason. --- Desired behavior after the commit is merged: This commit changes the values in the exported file to address those issues and adds the use of a cleanup helper to make the file human readable. --- task-5998939 Forward-Port-Of: odoo/enterprise#109359
5 changes
Resolved issues and error corrections
This update fixes a technical issue in the Odoo Studio view editor that previously caused crashes when interacting with certain fields. The fix ensures the sidebar correctly displays information, resolving a bug related to incorrect property computations. This improves the stability and usability of the Studio interface.
Original PR description
In studio, form editor: click on a field and check the sidebr is correct Click on another field, one that has the widget many2many_tags. Before this commit, there was a crash because the internals of the sidebar were computed with the wrong props (the old ones instead of the new ones) After this commit, there is no crash opw-6004776 Forward-Port-Of: odoo/enterprise#110391 Forward-Port-Of: odoo/enterprise#110284
This update resolves an issue preventing users from successfully creating events via the Quick Create feature within the Gantt view for Dental Care appointments. The fix ensures that users can now accurately schedule events when using this common workflow. This improves the usability of the appointment scheduling process.
Original PR description
Steps to reproduce: - Go to Appointments - Dental Care -> Gantt - Quick Create an event => bug task-6037337
A recent update to the payruns module has broken the generation of demo payslips in the HK payroll system. This pull request addresses this issue, restoring the ability to create these test payslips for verification and reporting. This ensures continued functionality for testing and demonstration purposes.
Original PR description
Following recent changes on payruns, the generation of demo payslips is no longer functioning, so we need to fix it.
This update reorganizes the testing for our SEPA payment module (hr_payroll_account_iso20022) to better align with its dependencies. Previously, a test needed to rely on the Accounting module, which has now been resolved by moving the test to a new, dedicated test module dependent on Accounting. This improves the module's structure and reduces unnecessary dependencies.
Original PR description
hr_payroll_account_iso20022, which is the module supporting SEPA payments, shouldn't be dependent on Accounting, but only on Invoicing. To solve a runbot error related to a test in this module, the dependency was changed to be Accounting instead of Invoicing. After more consideration, it is instead the test that should be moved to a new test module which depends on Accounting, leaving the original module only dependent on Invoicing. Task: 5979666
This update reverts a recent change to the spreadsheet edition's testing framework. The previous update introduced issues with tests related to a style refactor. This reversion ensures the spreadsheet edition's testing remains stable and reliable.
Original PR description
This reverts commit 8f22766dac4028ce7c726a036a9ba6f7c2df2c26.
2 changes
Resolved issues and error corrections
This update fixes an issue where timesheet descriptions were being duplicated when updating values in the grid view. The fix ensures that new timesheet lines created from updated values retain the original description, maintaining accurate reporting and data consistency. This improves the usability of the timesheet feature.
Original PR description
To reproduce: ============= - on timesheet group by Project > Task > Description - on a line with a description, update a 0:00 cell to an other value - refresh or change view to list and back to grid - a new line with description '/' is created with the updated value Problem: ======== when creating the new timesheet it's by default given the name '/' which for the grid view is not in same group as the original line with the description. Solution: ========= when creating the new timesheet, we give it the same description as the original line. opw-5909249 Forward-Port-Of: odoo/enterprise#108894
This update resolves an issue where text fields in Odoo Sign PDFs were incorrectly displayed as checkmarks. The fix ensures that text field values are accurately rendered, preventing misinterpretation of standard text fields as checkboxes during the PDF flattening process. This improves the accuracy and reliability of digital signatures.
Original PR description
Create an interactive PDF form in Adobe Acrobat containing a standard Text Field (/FT /Tx). - Fill the text field with a value (e.g., "John Doe") and save the PDF. - (Note: Adobe Acrobat will often…
Create an interactive PDF form in Adobe Acrobat containing a standard Text Field (/FT /Tx). - Fill the text field with a value (e.g., "John Doe") and save the PDF. - (Note: Adobe Acrobat will often automatically assign an Appearance State (/AS /N) to this text field). - Upload this PDF to the Sign app. **Current behavior:** The text field's string value is ignored and replaced with a checkmark (✓). **Expected behavior:** The text field should correctly render the string value that the user entered. **Cause of the issue:** In the _draw_field_value function, the parser checks if an /AS (Appearance State) tag exists and is not set to /Off. If true, it assumes the field is a checked box and draws a chr(0x2713). However, it fails to check the Field Type (/FT) first. Because Adobe Acrobat sometimes assigns /AS tags to standard Text Fields (/FT /Tx), we misinterprets these populated text fields as checked buttons. **Solution:** This PR fixes the issue safely for stable versions across two commits: [REF]: Extracts the value extraction logic into a dedicated _get_field_value helper method to allow isolated unit testing without requiring a canvas or physical PDF files. No behavioral changes in this commit. [FIX]: Wraps the /AS check within an if field_type == "/Btn": condition. This ensures only actual Checkboxes and Radio Buttons render as checkmarks, allowing Text Fields to fall through and properly return their /V string values. Task: 6018260
17 changes
Resolved issues and error corrections
This update streamlines the handling of discount calculations within the Point of Sale system. The logic for retrieving discount lines has been moved to the dedicated `pos_discount` module, improving organization and efficiency. This change ensures more accurate and reliable discount application during sales transactions.
Original PR description
Previously, the logic for retrieving discount lines was implemented in the `point_of_sale` module, while the `discount_product_id` was managed in the `pos_discount` module. This commit fixes the logic by moving the `_get_discount_lines` method into the `pos_discount` module. task-5875158
This update resolves an issue where users couldn't edit quantities within the pickup list view of the industry_fsm_stock module. By enabling multi-editing, users can now efficiently update multiple pickup records simultaneously, streamlining the picking process and improving operational efficiency.
Original PR description
Steps to reproduce: Steps to reproduce: - Install `industry_fsm_stock` - Create a task and add a product - Click on the Sale Order button - Add another product with the Invoicing Policy set to Delivered quantities - Click on the To Pickup button Issue: User is not able to edit fields in the list view. Fix: Enable `multi_edit` on the list view to allow editing multiple records. Task-5969303
This update corrects a potential customer misunderstanding in the Spanish translation of the 'No Tax Breakdown' checkbox within the Mexican e-commerce invoicing process. The original translation was causing confusion, and this change ensures clearer communication regarding tax breakdown options for Mexican customers. This improves the user experience and compliance.
Original PR description
**Steps to reproduce:** - Install l10n_mx_edi_website_sale - Activate "Spanish (Latin America)" language - Go to "Website / Configuration / Settings" - Configure the website: * Company: [a Spanish company] * Languages: [English, Spanish (Latin America)] - With a public user, go the the ecommerce page - Add a product to the cart - Proceed to checkout - Enter an address in Mexico - Continue checkout - When asked for an invoice, select "Yes" - A "No Tax Breakdown" checkbox should appear - Change the language to "Spanish (Latin America)" **Issue:** The Spanish translation of "No Tax Breakdown" is "No sujeto de desglose". Apparently, it can be misunderstood by customers. opw-4302562
This pull request resolves several issues identified during testing of the Sale PDF Quote Builder module. The changes focus on correcting errors in the test suite, ensuring the module functions as intended and improving overall stability. This update doesn't impact the core functionality of the module but strengthens its reliability.
Original PR description
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 resolves an issue where ticket buttons in the Helpdesk module were incorrectly identified as links, preventing them from functioning properly. The change ensures buttons are correctly recognized by the editor, improving the user experience when editing ticket details.
Original PR description
Without the `btn` class, buttons are identified as links by the editor. This commit adjusts the buttons inside the mail templates so that they are properly handled by the editor. Steps to reproduce: - Have demo data - Turn on developer mode - Go to Helpdesk > Customer Care - Open ticket "Where can I download a catalog?" - In the debug menu, go to Messages - Open the first template - Click on the "View Ticket" button - Edit the link => The link popover recognized it as a link instead of a button. As of saas-18.2, the style is replaced by a plain link style when changing the URL. task-5948539
A technical issue in the composer was causing errors when users selected mentions. This update corrects a renaming of an internal attribute that was causing the problem, ensuring mentions now function correctly. This improves the user experience when using the composer.
Original PR description
Problem: Opening the composer, typing "@" and selecting any item causes a traceback. Cause: After 8c99b17fcc3a612fd897da9ee29e2f53254d5933, the attribute `channel` was renamed to `thread`. Some code still referenced the old `channel` attribute, leading to errors when selecting mentions. Steps to reproduce: - Open the composer. - Type "@" to trigger mentions. - Select any item from the suggestions. - Observe a traceback. opw-6030307 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This pull request resolves a minor issue preventing users from correctly accessing a guided tour within the industry_fsm_report module. The fix ensures the tour functionality is properly enabled and accessible, improving the user onboarding experience. This change addresses a reported usability problem.
Original PR description
task-4489657
This update resolves an issue where cancelled vendor bills were incorrectly included in the Sweden (l10n_se) SIE export file. The fix ensures that cancelled transactions are accurately reflected in the General Ledger, aligning the export with the accounting records. This prevents discrepancies in reporting.
Original PR description
Steps to reproduce: - Install l10n_se (Sweden - Accounting). - Create a Vendor Bill with a line using Account 4000 (Cost of goods) for any amount (e.g., 10,000 SEK). - Confirm/Post the bill. - Cancel the bill. - Go to Accounting > Reporting > SIE Export and generate the export for the current year. - Open the downloaded .se file and locate the #RES line for Account 4000. Expected: The balance should be 0.00 (cancelled entries must be ignored, matching the GL). Actual: The cancelled amount (10,000) is incorrectly summed into the exported balance. opw-5901999 Forward-Port-Of: odoo/enterprise#108767
This update fixes a persistent problem where Chrome was creating unnecessary temporary files, leading to potential performance issues. By directing Chrome to use its temporary directory as its data directory, we now automatically clean up these files during testing, ensuring a smoother and more reliable testing environment. This resolves a technical issue that could impact test stability.
Original PR description
It's unclear since when or under what configuration exactly, but Chrome(ium?) seems prone to creating directories called `org.chromium.Chromium.*` (or some variant thereof) in the temp dir (some people report them to be prefixed by a `.`) and never clean them. By telling chromium that its tempdir is its data dir, it creates its litter in there, and we remove the entire thing during cleanup, solving the littering. Forward-Port-Of: odoo/odoo#253350
This update fixes an issue where presence notifications were sometimes inaccurate due to stale data. Now, notifications are only sent after a user's presence is fully removed, ensuring the correct 'offline' status is broadcast. This improves the reliability of presence information.
Original PR description
Before this commit, presence channel notifications for unlinked records were sent before the records were actually removed from the database. This caused `im_status` to be calculated using stale data, occasionally resulting in statuses other than "offline" being broadcast. This commit ensures notifications are sent only after the presences have been unlinked, guaranteeing an accurate status. Forward-Port-Of: odoo/odoo#249314
This update resolves an issue where long tax amounts on invoices were causing display problems. The fix ensures tax tables are correctly rendered, regardless of the size of the numbers, improving invoice clarity for users. This enhancement ensures accurate reporting and a better user experience.
Original PR description
This commit aims to: Fix Display issue when the amount is long. task-5162891 Forward-Port-Of: odoo/enterprise#100319
This update resolves a technical error that prevented users from placing lunch orders with vendors when a 'Until date' was set. The fix ensures the system correctly handles date comparisons, preventing a traceback and allowing users to successfully create orders. This improves order processing reliability.
Original PR description
Steps to reproduce: ------------------------------ 1. Install Lunch module 2. Lunch > configurations > Vendors 3. Open any vendor and set Until date to any near future date 4. Go to My Lunch > New Order 5. Click on Any product with above vendor > Add to Cart 6. Click on Order Now Observation: ------------------------------ Traceback Occurs: ``` return not (self.recurrency_end_date and date.date() >= self.recurrency_end_date) and self[fieldname] ^^^^^^^^^ AttributeError: 'datetime.date' object has no attribute 'date' ``` Issue: ------------------------------ `_available_on_date` calls `date.date()` unconditionally, which fails when passed a `datetime.date` object (from `lunch.order`) since date objects lack the `date()` method. Solution: ------------------------------ Check instance type before calling `date()` to handle both `datetime.datetime` and `datetime.date` objects correctly. opw-5948688
This update fixes errors in the Dutch SBR report exports, specifically correcting VAT identifiers and date formats. It also cleans up the XML formatting for improved readability, ensuring accurate and easily understandable reports.
Original PR description
Descriptions of the issues this commit addresses: The xbrli:identifier tags in the exported sbr and sbr icp files are wrong. They should always contain the company's vat without country code . The DateTimeCreation tag currently shows a date in a wrong format. It it YYYYMMDDhhmm but should be YYYY-MM-DDThh:mm:ss. Also the outputted xml is weirdly indented with many whitespaces and it makes it hard to read for no reason. --- Desired behavior after the commit is merged: This commit changes the values in the exported file to address those issues and adds the use of a cleanup helper to make the file human readable. --- task-5998939 Forward-Port-Of: odoo/enterprise#109359
This update ensures that the 'File' constructor in Odoo correctly identifies the MIME type of uploaded files, aligning with modern web standards. This change, prompted by a Chrome update, improves compatibility and prevents potential issues with file handling across different browsers.
Original PR description
The `type` option passed to the `File` constructor should be a string representing the MIME type of the content that will be put into the file. Chrome 146 actually follows the Fetch Standard and preserve the data URL MIME type parameter. This commit fixes the malformed MIME types passed to the `File` constructor to ensure proper compatibility with pre/post Chrome version 146 (and actually follow the spec). References: - https://chromestatus.com/feature/4874471565557760 - https://developer.mozilla.org/en-US/docs/Web/API/File/File#type runbot-241901 Forward-Port-Of: odoo/odoo#253631
This update ensures Odoo correctly handles file uploads, particularly in older versions of Chrome. The change fixes a technical issue related to MIME types, aligning with web standards and improving compatibility across different browsers. This ensures files are processed correctly and prevents potential display or functionality problems.
Original PR description
The `type` option passed to the `File` constructor should be a string representing the MIME type of the content that will be put into the file. Chrome 146 actually follows the Fetch Standard and preserve the data URL MIME type parameter. This commit fixes the malformed MIME types passed to the `File` constructor to ensure proper compatibility with pre/post Chrome version 146 (and actually follow the spec). References: - https://chromestatus.com/feature/4874471565557760 - https://developer.mozilla.org/en-US/docs/Web/API/File/File#type runbot-241901 Forward-Port-Of: odoo/enterprise#110496
This update addresses a potential issue where a new Odoo database could unintentionally create demo data, polluting the system. The change restricts the 'try our sample' option to the dashboard widget, reducing the risk of users adding unnecessary demo records. This improves data integrity and simplifies database setup.
Original PR description
When accessing the accounting module's dashboard on a new database, the bills widget displays the option to "try our sample" bill, which will create a contact record (Deco Addict), several products…
When accessing the accounting module's dashboard on a new database, the bills widget displays the option to "try our sample" bill, which will create a contact record (Deco Addict), several products and categories, and a vendor bill with this newly created demo data prepopulated. This option to "try our sample" not only exists on the bills widget in the Accounting dashboard on a fresh database, but exists in the bills list view if either there are no bills in the database, or if a search filter is applied such that the result set is empty. The implementation is problematic for two reasons: 1. It is not made clear to the user that several database models will be populated with demo data. 2. The "try our sample" button is presented to users outside of its intended context. The current implementation does not clearly communicate to the user that they will be creating real demo records in several models on their database, which would obviously pollute a production database. Being that we provide an explicit warning when demo data is enabled for the whole database, a similar confirmation seems appropriate in this case, which has been added. Additionally, it does not seem appropriate that the "try our sample" option should be present in the list view. This is because its intent is to allow the user to try the bill functionality in the case that their database does not have any data. When a user is in the list view, more often than not will users who have applied an invalid search filter on existing data be shown the option, rather than new users on a new database. This can cause accidental addition of demo data. By only presenting the option only in the dashboard widget, it is far more likely that this prompt is shown only in the intended context. Enterprise PR: https://github.com/odoo/enterprise/pull/93352 opw-4959767
This update addresses a potential issue where a new database would automatically create demo data, polluting the system. The change clarifies the 'try our sample' option's purpose and restricts its display to the dashboard, reducing the risk of unintended data creation. This ensures a cleaner, more controlled environment for new users.
Original PR description
When accessing the accounting module's dashboard on a new database, the bills widget displays the option to "try our sample" bill, which will create a contact record (Deco Addict), several products…
When accessing the accounting module's dashboard on a new database, the bills widget displays the option to "try our sample" bill, which will create a contact record (Deco Addict), several products and categories, and a vendor bill with this newly created demo data prepopulated. This option to "try our sample" not only exists on the bills widget in the Accounting dashboard on a fresh database, but exists in the bills list view if either there are no bills in the database, or if a search filter is applied such that the result set is empty. The implementation is problematic for two reasons: 1. It is not made clear to the user that several database models will be populated with demo data. 2. The "try our sample" button is presented to users outside of its intended context. The current implementation does not clearly communicate to the user that they will be creating real demo records in several models on their database, which would obviously pollute a production database. Being that we provide an explicit warning when demo data is enabled for the whole database, a similar confirmation seems appropriate in this case, which has been added. Additionally, it does not seem appropriate that the "try our sample" option should be present in the list view. This is because its intent is to allow the user to try the bill functionality in the case that their database does not have any data. When a user is in the list view, more often than not will users who have applied an invalid search filter on existing data be shown the option, rather than new users on a new database. This can cause accidental addition of demo data. By only presenting the option only in the dashboard widget, it is far more likely that this prompt is shown only in the intended context. Community PR: https://github.com/odoo/odoo/pull/224328 opw-4959767
11 changes
Resolved issues and error corrections
This update resolves a bug that prevented users from successfully merging contacts when removing one of the associated customers. The fix ensures the system handles multi-customer contact merging more reliably, preventing data errors and improving the customer management process.
Original PR description
When we select multiple customers and attempt to merge their contacts by removing one of the customers, this error occurs. Steps to reproduce: - Install the l10n_in module - Switch to IN company - Invoicing > Customers >Customers - Go to list view > Select all Customers > Actions > Merge - Click on Deco Addict, now come back and remove it - Click on Merge Contacts -> Traceback: ValueError: Expected singleton ...
This update fixes a potential issue where Mail Defender services could inadvertently cancel appointments through automated email interactions. A new form has been implemented to replace the original 'cancel/reschedule' link, preventing bots and automated systems from triggering cancellations. This ensures appointments are handled correctly and reliably.
Original PR description
…ointments Mail defender services may click URLs in emails to verify their contents. Additionally they may sometimes interact with the page and visit related pages. For this reason URLs sent in emails should not trigger any action directly nor contain any simple link that could trigger an action. The "cancel/reschedule" anchor URL is replaced with a form which bots should not click. We also port the fix done in appointment to the view in appointment as it replaces the original view in this module. task-4555579
This update ensures that the 'File' constructor in Odoo correctly identifies the MIME type of uploaded files. This change aligns with Chrome's latest standards, improving compatibility and preventing potential issues with file handling across different browser versions. It's a minor fix that enhances the reliability of file uploads.
Original PR description
The `type` option passed to the `File` constructor should be a string representing the MIME type of the content that will be put into the file. Chrome 146 actually follows the Fetch Standard and preserve the data URL MIME type parameter. This commit fixes the malformed MIME types passed to the `File` constructor to ensure proper compatibility with pre/post Chrome version 146 (and actually follow the spec). References: - https://chromestatus.com/feature/4874471565557760 - https://developer.mozilla.org/en-US/docs/Web/API/File/File#type runbot-241901
This update ensures that files created within the Odoo Enterprise system correctly identify their file type (MIME type) when used with older versions of Chrome. The change aligns with modern web standards, improving compatibility and preventing potential issues with file handling in different browsers.
Original PR description
The `type` option passed to the `File` constructor should be a string representing the MIME type of the content that will be put into the file. Chrome 146 actually follows the Fetch Standard and preserve the data URL MIME type parameter. This commit fixes the malformed MIME types passed to the `File` constructor to ensure proper compatibility with pre/post Chrome version 146 (and actually follow the spec). References: - https://chromestatus.com/feature/4874471565557760 - https://developer.mozilla.org/en-US/docs/Web/API/File/File#type runbot-241901
This update fixes a persistent problem where Chrome was creating unnecessary temporary files, leading to potential performance issues. By directing Chrome to use its temporary directory as its data directory, we now automatically clean up these files during testing, ensuring a cleaner and more stable testing environment. This resolves a technical issue that could impact test stability.
Original PR description
It's unclear since when or under what configuration exactly, but Chrome(ium?) seems prone to creating directories called `org.chromium.Chromium.*` (or some variant thereof) in the temp dir (some people report them to be prefixed by a `.`) and never clean them. By telling chromium that its tempdir is its data dir, it creates its litter in there, and we remove the entire thing during cleanup, solving the littering. Forward-Port-Of: odoo/odoo#253350
This update resolves a problem where tours on the website were failing to load translations correctly, particularly with recent Chrome versions. The change introduces a temporary step to ensure translations load before the tour begins, preventing delays and ensuring a smoother user experience.
Original PR description
This commit adds an intermediary step ensuring the proper page has been reached before actually doing the checks and avoiding to let startup requests (like the loading of the translations) pending at the end of the tour (and the eventual stop of the runner browser). Note: this is most likely due to a timing (indeterministic by nature) change, emphasised by recent Chrome versions (like v145). runbot-239128
This update resolves a problem where the website's onboarding tour wasn't loading translations correctly, particularly for tour requests. The change ensures translations load promptly, preventing delays and improving the user experience. This fix addresses an intermittent issue related to timing differences in Chrome browsers.
Original PR description
This commit adds an intermediary step ensuring the proper page has been reached before actually doing the checks and avoiding to let startup requests (like the loading of the translations) pending at the end of the tour (and the eventual stop of the runner browser). Note: this is most likely due to a timing (indeterministic by nature) change, emphasised by recent Chrome versions (like v145). runbot-239128
This update fixes errors in the Dutch SBR report exports, specifically correcting VAT identifiers and date formats. It also cleans up the XML formatting for improved readability, ensuring accurate and easily understandable reports.
Original PR description
Descriptions of the issues this commit addresses: The xbrli:identifier tags in the exported sbr and sbr icp files are wrong. They should always contain the company's vat without country code . The DateTimeCreation tag currently shows a date in a wrong format. It it YYYYMMDDhhmm but should be YYYY-MM-DDThh:mm:ss. Also the outputted xml is weirdly indented with many whitespaces and it makes it hard to read for no reason. --- Desired behavior after the commit is merged: This commit changes the values in the exported file to address those issues and adds the use of a cleanup helper to make the file human readable. --- task-5998939 Forward-Port-Of: odoo/enterprise#109359
This update fixes a bug that caused product variant combinations to get stuck in an infinite loop under specific attribute configurations. The change ensures the algorithm correctly progresses through options, preventing repeated, incorrect results. This improves the reliability of product configuration and reduces potential errors.
Original PR description
ISSUE: When generating product variant combinations, the cartesian product algorithm enters an infinite loop whenever the attribute lines follow the pattern: non-empty → empty → non-empty. In this…
ISSUE: When generating product variant combinations, the cartesian product algorithm enters an infinite loop whenever the attribute lines follow the pattern: non-empty → empty → non-empty. In this case, the DFS backtracking logic incorrectly returns to the empty middle line, which always forwards execution to the next line instead of propagating the backtrack upward. This causes the search to oscillate between the empty line and the deeper non-empty line, never allowing the first line to advance to its next value and repeatedly yielding the same combinations. FIX: This fix introduces a minimal, localized change: during backtracking, the algorithm now skips backward over empty attribute lines until it reaches a line that actually has selectable values (or reaches the root). This preserves all existing behavior, avoids altering the core iteration logic, and ensures that the DFS always makes progress and terminates properly. The change avoids modifying exclusion logic or altering the order of generated combinations. It simply ensures that empty intermediate lines do not trap the state machine in a loop. opw-5231175
This update ensures that customers download attachments from the customer preview of Sale Orders with the correct file name. Previously, the file name was inconsistent when downloading through the portal compared to the standard Sale Order form. This change improves the customer experience and data integrity.
Original PR description
Issue --> On the customer preview of a Sale Order, when the customer selects `View Details`, an attachment is opened on a new tab, and upon downloading it, the file name is different than if the report was downloaded via the Sale Order form view. Solution --> Add the `inline` option to the 'Content-Disposition' response header so that the file name is added in the case that a customer decides to download the attachment from the attachment preview. opw-4091262
This update resolves a problem where the system was incorrectly referencing a group of records instead of a single company record. This prevented proper processing of tax-related data for the l10n_be_codabox module. The fix ensures accurate data handling for this specific Odoo module.
Original PR description
We incorrectly used the recordset `self` instead of the record `company` This commit fixes this. Backport of PR https://github.com/odoo/enterprise/pull/94289 opw-6034633