Monday, March 16, 2026
17 changes · 18.0
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