Daily updates from Odoo
Wednesday, March 18, 2026
65 changes · saas-19.1
Enhancements to existing features
This update simplifies printer setup for our Point of Sale users by adding a step-by-step checklist within the POS configuration form. This guide will walk clients through the necessary actions to enable LNA access for their printers, reducing setup complexity and improving user satisfaction.
Original PR description
The LNA configuration for printers is complicated for users. To help them this PR will add a check list document inside the point of sale form view which will explain all the steps the clients should do to enable LNA access for their printers in the browser. Task-[5933321](https://www.odoo.com/odoo/project/1737/tasks/5933321) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249226
This update enhances our testing process by allowing developers to easily specify the Chrome browser version used during tests. This simplifies debugging issues related to browser-specific breaking changes, leading to faster identification and resolution of problems. It's a small improvement that strengthens our overall testing and stability.
Original PR description
This is mainly used to more easily provide an arbitrary version of Chrome/Chromium to debug browser's version specific breaking changes. Forward-Port-Of: odoo/odoo#253630
This update aligns the Odoo Chart of Accounts with Chinese accounting standards (ASBE and ASSBE). A key change is the introduction of dot notation in account codes, improving readability and navigation for Chinese users and aligning with local industry practices.
Original PR description
### [IMP] l10n_cn: update CoA We update the Chart of Accounts to align with the latest ASBE and ASSBE standards. Notably, this introduces the dot (.) notation in account codes to clearly signify parent-child hierarchies. This format matches local industry standards, making the accounts much easier to read and navigate for Chinese users. enterprise-[109175](https://github.com/odoo/enterprise/pull/109175) task-[5939988](https://www.odoo.com/odoo/all-tasks/5939988) Forward-Port-Of: odoo/odoo#251681
This update ensures our Balance Sheet and Profit & Loss reports align with the latest accounting standards for Chinese businesses (ASBE and ASSBE). The changes improve the clarity and consistency of these reports, simplifying financial reporting for our Chinese clients.
Original PR description
### [IMP] l10n_cn_reports: update BS & PnL We update the Balance Sheet and Profit & Loss reports to be consistent with updated ASBE and ASSBE standards odoo-[251681](https://github.com/odoo/odoo/pull/251681) task-[5939988](https://www.odoo.com/odoo/all-tasks/5939988) --- We encountered an issue where setting `groupby = False` still resulted in an error (no groupby and children lines). This was resolved by setting a co-dependent variable `user_groupby = False`. The reports has lines with "Includes:" and sibling lines' name are expected to be aligned with it. Hierarchy lines and using various space characters (CJK space `　`, and "en" space ` `) was a maintenance nightmare. We instead chose to remove `includes:` as it's implied by the natural indentation of grouped lines. Forward-Port-Of: odoo/enterprise#109175
Resolved issues and error corrections
This update resolves an issue where timesheet descriptions were being duplicated when updating timesheet entries in the grid view. The fix ensures that new timesheet lines created after an update retain the original description, maintaining data accuracy and consistency for reporting.
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#110554 Forward-Port-Of: odoo/enterprise#108894
This update fixes a visual inconsistency in the Odoo calendar view for timesheets. Previously, negative time entries were displayed as '-1h 15m', which was confusing. Now, the calendar view accurately reflects negative durations like '-45 minutes', aligning with how they're shown in the list view for clarity and accuracy.
Original PR description
The calendar view used Python's `divmod` for time calculations, which renders -45 minutes as -1h 15m. This representation is misleading for timesheet entries, while the list view already displays the values correctly. Adjust the calendar view logic to ensure consistent and accurate handling of negative durations. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247925
This update resolves a technical error that prevented users from placing lunch orders with vendors when a 'Until Date' was specified. The fix ensures the system correctly handles date comparisons, preventing a traceback and allowing users to complete their orders. This improves the reliability of the Lunch module.
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 Forward-Port-Of: odoo/odoo#249449
This update fixes an issue where the product search bar on the mobile version of the website wasn't functioning correctly. The fix ensures that searches are processed properly, allowing users to find products effectively on their mobile devices. This improves the overall shopping experience for mobile users.
Original PR description
Steps to produce: --- - Install `website_sale` module. - Go to `website > shop`. - Open the `Customizable Desk` product page. - From the website editor, `enable the search bar` for the product page.…
Steps to produce: --- - Install `website_sale` module. - Go to `website > shop`. - Open the `Customizable Desk` product page. - From the website editor, `enable the search bar` for the product page. - Switch to `mobile view`. - Now search for `drawer` in product search. Issue: --- - In mobile view, the search does not work. When performing a search, nothing happens, and the request is not executed. Root cause: --- - At [1], in the search template definition, the action attribute is missing in the search form. Solution: --- - Set the form action using keep(search=0) instead of leaving it undefined. - This ensures that the search behaves correctly depending on the context (global or category-scoped). [1]https://github.com/odoo/odoo/blob/51f59a293de1e86f66f30257f8fc0c419463d18c/addons/website_sale/views/templates.xml#L2239-L2259 opw-5992052 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251694
This update fixes a problem where image uploads would fail and cause a confusing user experience. Now, when you discard an image upload, the process stops cleanly, preventing errors and ensuring a smoother user experience. The fix ensures files are no longer uploaded after discarding the media dialog.
Original PR description
Steps to Reproduce: 1. Open the website module. 2. Open the media upload dialog to upload an image by either double-clicking the logo or replacing the existing image. 3. Upload a large file. 4. Abort…
Steps to Reproduce: 1. Open the website module. 2. Open the media upload dialog to upload an image by either double-clicking the logo or replacing the existing image. 3. Upload a large file. 4. Abort the upload before it finishes by clicking the 'Discard' button in the media dialog box. After performing these steps, a traceback is observed. Before this commit: - Image upload failures would throw uncaught exceptions. - These exceptions would interrupt the flow and result in a poor user experience with no clear feedback. - Even after clicking the discard button the image was still getting uploaded. After this commit: - Uploads can be safely aborted when the media dialog is discarded. - Ongoing XHR requests and RPC calls are properly cancelled. - The upload loop stops immediately when an abort is triggered with no traceback. - Users get a predictable and clean exit instead of a broken state. - Files are no longer uploaded after clicking Discard. ### task-4752497 Forward-Port-Of: odoo/odoo#250065 Forward-Port-Of: odoo/odoo#219081
This update resolves an issue where clicking on 'reply' links within Odoo mailboxes didn't function correctly. Now, clicking on a reply link will automatically take the user to the original conversation thread, improving the user experience and ensuring messages are easily accessible within their email chains.
Original PR description
Before this change, clicking on a `message in reply` in mailboxes had no effect. The expected behavior is for it to jump to the message in its origin thread. To fix it, this commit ensures that `useMessageHighlight` hook receives the correct thread which in this case is the origin thread of the message in reply. task-5343804 Forward-Port-Of: odoo/odoo#253990 Forward-Port-Of: odoo/odoo#253334
This update fixes an issue where upload widgets within dropdown menus on smaller screens wouldn't function correctly. The fix ensures that dropdowns remain open while users initiate uploads, improving the user experience for mobile and tablet users. This resolves a bug preventing users from uploading documents from purchase orders.
Original PR description
## Issue: On small screens, when an upload widget is placed inside a dropdown (e.g., Upload Bill from a Purchase Order), the action does not work Clicking the dropdown item closes the dropdown immediately, which prevents the widget action from completing ## Cause: Widget actions require an accessible anchor element to function properly. However, dropdown items automatically close the dropdown on click As a result, the widget is triggered but immediately detached from the DOM before its action can fully execute ## Steps to reproduce: - Install `purchase_stock` (to have the Upload Bill widget available) - Create and confirm a Purchase Order (the Receive button must be available) - Reduce the browser width until the action buttons collapse into the three-dots menu - Click Upload Bill and try to upload a document opw-5918379 Forward-Port-Of: odoo/odoo#251492
This update corrects a naming error in the ZUGFeRD eInvoice XML file generated by our system. Previously, the file name didn't meet validator requirements, causing issues with several e-invoice validation services. Now, the ZUGFeRD file is correctly named, ensuring compatibility with key validation tools and facilitating accurate e-invoice processing.
Original PR description
Fix the name of the embedded xml for zugferd eInvoice format. Before this PR: For the validator https://www.portinvoice.com/en/, the error > No, the file is called zugferd.xml. The following naming conventions are > permitted: “factur-x.xml”, “xrechnung.xml”, “zugferd-invoice.xml”, > “ZUGFeRD-invoice.xml”, “order-x.xml”, “cida.xml” And also: > The XML has a valid profile? No This corresponds to the document_context, as the french factur-x and the german ZUGFeRD are a common standard, we can put the same context. After this PR: The ZUGFeRD file passes on different validators. Validators: * https://erechnungs-validator.de/ * https://easyfirma.net/e-rechnung/validieren * https://www.portinvoice.com/en/ * https://demo.verapdf.org/ task-6010416 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253704 Forward-Port-Of: odoo/odoo#252681
This update fixes an issue where unbuilding products from different companies resulted in incorrect pricing due to a mismanaged company context. The fix ensures that component pricing accurately reflects the company from which the unbuild order originates, resolving discrepancies in inventory valuation reports.
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 Forward-Port-Of: odoo/odoo#249790
This update corrects a previous issue where event ticket prices were fixed and not recalculated within the Point of Sale system. Now, event tickets will dynamically adjust their price based on either the event's defined price or the customer's active pricelist, ensuring accurate pricing at the POS. This improves the overall POS experience and pricing accuracy for event tickets.
Original PR description
Event tickets in POS would have their price locked to the price defined in the event itself. They would be filtered out of any price recalculation inside the POS to keep the POS from recalculating the price based on the `product_template` and to keep the price defined in the event itself. This PR will add event tickets back into price recalculation. It will set the price to the price defined inside the event if no pricelist is applicable, or use the pricelist to calculate the price if there is one applicable. Task-[5092613](https://www.odoo.com/odoo/project/1737/tasks/5092613) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248454
This update fixes an issue where group leave durations were incorrectly calculated when overlapping with existing approved leave requests. The fix ensures that group leave durations accurately reflect all allocated time off, resolving a discrepancy in how the system processed conflicting leave types. This improves the reliability of time off scheduling.
Original PR description
Problem ------------------------ When an employee has approved leaves, and a group leave is created that overlaps with the approved leave and overrides it, the duration of the new group leave is not…
Problem ------------------------ When an employee has approved leaves, and a group leave is created that overlaps with the approved leave and overrides it, the duration of the new group leave is not computed correctly. The duration does not include the overridden days. To reproduce: 1. Create allocated leave for employee and approve and validate it. 2. Go to Management > Time Off and create a group leave for the employee that includes the approved time off dates. The dates of all leaves are updated correctly, but the duration of the group leave is incorrect. Objective --------------------------- Even though conflicting leaves were correctly split in the multi leave generation wizard, the resource.calendar.leaves table was not synchronized within the same transaction. Because the leave types required allocation, the duration was computed by subtracting the old time off days from the new leave's duration, since they were treated as unavailable. Solution -------------------------- Manually unlink the resource.calendar.leaves records associated with the conflicting leaves before calculating the new duration. The clears the employee's schedule in the database so that the dates are correctly processed as available. The calendar blocks for the remaining days of the approved time off and the new group leave are generated when the leaves are created. Task: 5911074 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253425 Forward-Port-Of: odoo/odoo#249527
This update resolves an issue where salespeople without project access were unable to open sale orders with timesheet entries. The fix uses `sudo()` to bypass access restrictions when determining button visibility, ensuring all salespeople can manage timesheets on sale orders.
Original PR description
to reproduce: ============= - create a user with only user access to timesheet and no access to project - create and confirm a sale order with a timesheet-delivered service product assigned to that salesperson - record some hours on that SO with another user - open the sale order as that salesperson -> AccessError problem: ======== `_compute_show_hours_recorded_button` reads `timesheet_count` and `project_count` on the sale order, which internally query `account.analytic.line` and `project.project` records. a salesperson without all timesheet or project groups lacks read access to those models, causing an AccessError during the compute. solution: ========= use `sudo()` since the result is only used to determine button visibility and does not expose sensitive data to the user. opw-5893324 Forward-Port-Of: odoo/odoo#248026
This update corrects a warning related to outdated cryptography libraries used in our payment processing system (payment_redsys). The change ensures compatibility with newer versions of the cryptography library, preventing potential issues and maintaining a stable payment experience for our customers.
Original PR description
In cryptography 43.0.0 (present in Debian Trixie), ARC4 and TripleDES were migrated to decrepit [^1], leaving a deprecation warning in the old path. This commit handles both previous pre/post 43.0.0 import path. runbot-233267 [^1]: pyca/cryptography@722a6393e61b3acb569f404218f213fe08478a96 Forward-Port-Of: odoo/odoo#253957
This update fixes an issue where certain salary deductions (specifically 'ATTACH_SALARY') were not being correctly processed in the net calculation for Odoo's Kenyan payroll module. The changes ensure that these deductions are accurately accounted for, improving payroll accuracy and compliance.
Original PR description
**Behavior before this commit** Some salary rules (e.g. `ATTACH_SALARY`) were ignored in the NET calculation. **Behavior after this commit** - Four rules are now added to the "Total deductions" line: their sequence and category has been changed. - The sign of these lines has also been switched: an attachment of salary of a positive amount should be added to the amount of total deductions, which is then deducted from the net.  opw-5894647 Forward-Port-Of: odoo/enterprise#110367 Forward-Port-Of: odoo/enterprise#107033
This update prevents ribbon customizations from resetting to default settings when creating a new ribbon. Previously, changes made immediately after creation were lost due to a delay in the ribbon's database assignment. Now, the system waits for the ribbon to be fully created before applying updates, ensuring customizations are reliably saved.
Original PR description
When creating a new ribbon and immediately changing its options, the title and colors would unexpectedly reset to None. This happened because the ribbon was not fully saved in the database before we tried to update its settings, causing the changes to be lost. Now we wait for the ribbon to be properly created and assigned its database identifier before applying any updates. A mapping system tracks the relationship between temporary and final identifiers to ensure changes are always applied to the correct ribbon. task-5503716 Forward-Port-Of: odoo/odoo#227626
This update corrects a display issue in the employee emergency contact section for employees outside of India. Previously, the ‘Relationship’ field was incorrectly shown to all employees, regardless of their company location. This fix ensures the field is only visible for employees associated with Indian companies, improving data accuracy and user experience.
Original PR description
### Steps to reproduce: - Install l10n_in_hr_payroll. - Create an employee (also link a user) in an Indian company and another company. - Go to My Profile > Private Information > Emergency. - The Relationship field is shown for non-Indian employees as well as employees from other countries. ### Issue: - We're not hiding the relationship field if employee is from other country. ### Fix: - We'll hide this field if an employee belongs to non-indian company. Task: 6008888 Forward-Port-Of: odoo/enterprise#109775
This update fixes an issue where certain valid Non-Resident (NRI) GSTINs were not recognized by the partner autocomplete feature. The change updates the validation logic to accept a wider range of NRI GSTIN formats, ensuring accurate data entry for international business partners. This improves the usability of the system for users dealing with NRI clients.
Original PR description
Currently, certain `valid GSTINs` for Non-Resident taxpayers are not recognized by the partner `autocomplete` feature. **Steps to reproduce:** - Install the `l10n_in` and `partner_autocomplete`…
Currently, certain `valid GSTINs` for Non-Resident taxpayers are not recognized by the partner `autocomplete` feature. **Steps to reproduce:** - Install the `l10n_in` and `partner_autocomplete` modules. - Navigate to Settings > Users & Companies > Companies. - Click `New` and set `Tax ID` to `9922JPN29001OSU`. - Wait for 5–10 seconds. **Observation:** The partner autocomplete does not trigger, although it is valid and verifiable on the official GST portal: https://services.gst.gov.in/services/searchtp **Root Cause:** The issue was already fixed in core validation by PR [1], but the GSTIN validation logic used in partner autocomplete was not updated. At [2], the GSTIN validation regex for NRI taxpayers only supports formats ending with `NRX` (X = any alphanumeric character). However, certain valid GSTINs follow a revised structure and therefore are not matched by the existing regex. **Fix**: This commit ensures that valid NRI GSTIN formats are accepted during validation by applying a fix similar to [1] to the partner autocomplete GSTIN validation at [2]. Related IAP PR: https://github.com/odoo/iap-apps/pull/1491 [1]: https://github.com/odoo/odoo/pull/251760 [2]: https://github.com/odoo/odoo/blob/3016c08a7aa8701ec9b0092b5aafc282b16dd9f3/addons/partner_autocomplete/static/src/js/partner_autocomplete_core.js#L36-L52 Forward-Port-Of: odoo/odoo#253799
This update resolves an issue where image galleries could inadvertently share the same ID, leading to unexpected behavior when saving and refreshing website pages. The fix generates a truly unique ID for each gallery, preventing conflicts and ensuring consistent functionality across user sessions. This improves the stability and reliability of the website builder.
Original PR description
Commit [86a3f41] called `uniqueId()` to generate the image gallery id in the builder options. However, `uniqueId()` is only unique in the course of the current client session. As a result, you could drop a gallery, save your page, refresh it, edit the page and drop another gallery with the same id as the 1st one. Steps to reproduce: - Drop an image gallery - Save - Refresh - Go back to edit - Drop another image gallery => Check their ids. It's very probable that they are the same. - Save - Click on the "Previous" or "Next" arrow of the 2nd gallery => it updates the 1st carousel, not the 2nd one. [86a3f41]: https://github.com/odoo/odoo/commit/86a3f41a71a91c656a9969a4ef251f8c2ce3a266 Forward-Port-Of: odoo/odoo#253960
This update fixes an issue where time off leaves weren't displaying the correct return dates for employees. The fix ensures that all validated leaves, including worked-time leaves, now accurately calculate and display the employee's expected return date, improving the accuracy of employee schedules and reporting.
Original PR description
Issue: - When a time off type was configured as , adding a leave for today caused the employee form to display instead of a real date. Fix: - Compute leave dates for all validated leaves, including worked-time leaves. - Ensure the date is always computed using the first working interval after the leave end date. Impact: - Employee profiles now display a correct return date for worked-time leaves. task-5421688 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241329
This update resolves a sporadic test failure related to scrolling to notifications within the email system. The fix ensures messages are fully loaded before the scroll action, preventing conflicts with other UI elements and improving test reliability. This enhances the overall stability of the email functionality.
Original PR description
Before this commit, test 'Can scroll to notification' may fail non-deterministically with the following error: ``` [toBe] expected values to be strictly equal (Element…
Before this commit, test 'Can scroll to notification' may fail non-deterministically with the following error: ``` [toBe] expected values to be strictly equal (Element .o-mail-NotificationMessage:contains(notification 0) not found in viewport of .o-mail-Thread) ``` This happens because while the test is awaiting the scrolling to unread, this is made with just an `await tick()` after opening discuss app. This is not enough: messages need to be loaded and then there's a tick with scroll to unread message. The awaiting of messages being loaded was missing in the test, which this error is fixing. This is important because the opening of pinned panel and click on jump may be triggered before the auto-scroll to unread message, and this is a problem because the jump to pinned message would be cancelled by the scroll to bottom. Also instead of awaiting the tick for scroll to unread message, this commit replaces it by assertion of message list being at the bottom. This asserts precisely the scroll has happen, and its ok to have it scroll at bottom as the last message is short and is necessarily smaller than viewport, thus the auto-scroll to this unread message implies this scrolls to the bottom of message list. Fixes runbot-error-238427 Forward-Port-Of: odoo/odoo#253928
This update corrects a data issue in NACHA payment files by prioritizing the actual bank account holder's name over the customer's name in Odoo. Using the correct account holder name ensures accurate bank identification and avoids potential payment processing errors. This improves the reliability of US payments.
Original PR description
The NACHA entry detail was using the partner's name (res.partner.name) for the Individual Name field. This should instead prioritize the Account Holder Name (acc_holder_name) from the bank account, as this reflects the actual name on the bank account which may differ from the partner's name in Odoo. The code now uses bank.acc_holder_name if set, and falls back to payment.partner_id.name if not set. Forward-Port-Of: odoo/enterprise#108414 Forward-Port-Of: odoo/enterprise#105582
This update fixes an error in how credit notes calculate the cost of goods sold (COGS). Previously, the calculation was incorrect when the invoice's unit of measure differed from the product's. This change ensures accurate COGS reporting for credit notes, improving financial reporting accuracy.
Original PR description
…f uom **Problem:** partial cogs are computed incorrectly when the uom of the invoice is different than the one of the product **Steps to reproduce:** -1) created a stored product with category std…
…f uom **Problem:** partial cogs are computed incorrectly when the uom of the invoice is different than the one of the product **Steps to reproduce:** -1) created a stored product with category std price perpetual -2) set a cost of 1 and an on hand quantity of 12 -3) for the invoicing policy select 'delivered quantities' -4) in the sales tab add the packaging 'pack of 6' -5) confirm a sale order for 2 packs of 6 Problem A: -6a) validate the delivery -7a) create and confirm an invoice for all the quanity -8b) on the delivery create a return for a quantity of 6 and validate -9b) select 'create invoice' on the sale order -10b) confirm the credit note Problem B: -6b) change the quantity to 6 units on the delivery -7b) validate with backorder -8b) create and confirm an invoice for the delivered quantity (1 pack of 6) -9b) validate the back order -10b) create and confirm an invoice for the remaining (1 pack of 6) **Current behavior:** Problem A : the cogs lines are : - crediting stock valuation of 54$ - debiting expenses of 54$ Problem B: the cogs lines are: - debiting stock valuation of 24 - crediting expenses of 24 **Expected behavior:** Problem A: the cogs lines should be: - debiting stock valuation of 6 - crediting expenses of 6 Problem B: the cogs lines should be: - crediting stock valuation of 6 - debiting expenses of 6 **Cause of the issue:** Both problems have the same cause. To compute the price unit for the cogs we call _get_cogs_value() https://github.com/odoo/odoo/blob/b071bc3cb9e1d91d9d0fbce7961c3c75f28ef874/addons/stock_account/models/account_move.py#L122 Inside _get_cogs_value, in the computation of the return value: https://github.com/odoo/odoo/blob/b071bc3cb9e1d91d9d0fbce7961c3c75f28ef874/addons/stock_account/models/account_move_line.py#L74 - price_unit is computed (in both use cases) using _get_cogs_price_unit https://github.com/odoo/odoo/blob/b071bc3cb9e1d91d9d0fbce7961c3c75f28ef874/addons/stock_account/models/account_move_line.py#L68 and is expressed in the uom of the product https://github.com/odoo/odoo/blob/b071bc3cb9e1d91d9d0fbce7961c3c75f28ef874/addons/stock_account/models/stock_move.py#L238-L240 - self.quantity is expressed in the uom of the invoice (pack of 6) - cogs_qty is computed using _get_cogs_qty() https://github.com/odoo/odoo/blob/b071bc3cb9e1d91d9d0fbce7961c3c75f28ef874/addons/stock_account/models/account_move_line.py#L66 and is expressed in the uom of the invoices (pack of 6) Because of this, in both use cases, the computation is incorrect. **fix:** we use the uom of the product everywhere because _get_cogs_value() should return the price unit in the products uom https://github.com/odoo/odoo/blob/b071bc3cb9e1d91d9d0fbce7961c3c75f28ef874/addons/stock_account/models/account_move_line.py#L51-L52 opw-5901706 Forward-Port-Of: odoo/odoo#250154
This update fixes an issue where timesheets were incorrectly calculating hours for employees on past contracts. The change ensures that timesheets accurately reflect the employee's historical working hours based on their contract period, resolving a discrepancy between current and past contract data.
Original PR description
Currently on creating a time off that falls under a past contract still generates timesheet hours based on the employee's current contract. ### **Steps to Reproduce:** 1) Install…
Currently on creating a time off that falls under a past contract still generates timesheet hours based on the employee's current contract. ### **Steps to Reproduce:** 1) Install `project_timesheet_holidays` module with demo data. 2) Create an employee with two contracts/versions: - Past contract: 1 Jan 2025 to 31 Dec 2025 with standard 40h/week (8h/day). - Current contract: 1 Jan 2026 to indefinite with standard 35h/week (7h/day). 3) Create and validate Time off for this employee in the past (e.g, 29 Dec 2025) 4) Navigate to `Timesheets>All Timesheets`, search for this employee and switch list view for clear view. ### **Observed Behavior:** 7:00 hours are displayed on the timesheet, pulling from the employee's current active contract calendar. ### **Expected Behavior:** 8:00 hours should be displayed, as the leave date falls under the 40h/week past contract. ### **Root Cause:** In the `_generate_timesheets`, the caledar values is fetched using `employee_id.resource_calendar_id` see[1], which always points to the employee's currently active calendar. Furthermore, this calendar is not explicitly passed to `_list_work_time_per_day` see[1], causing the method to fall back on the current default. [1]- https://github.com/odoo/odoo/blob/c2595e47e3b36120f4c3da8bfe8c16f6c5969a70/addons/project_timesheet_holidays/models/hr_leave.py#L36-L55 ### **Fix:** Change the logic to use `leave.resource_calendar_id`, which correctly computes and retrieves the resource calendar active during the specific `date_from` and `date_to` of the leave and pass this `calendar` to `_list_work_time_per_day` to ensure the correct historical hours are used for timesheet generation. **opw-5922695** Forward-Port-Of: odoo/odoo#248207
This update resolves a technical issue that caused inconsistent test results in the HTML editor. The fix ensures the editor is fully loaded before tests attempt to interact with it, improving the reliability of the testing process. This contributes to overall product stability and reduces the risk of unexpected behavior.
Original PR description
See commit messages. Forward-Port-Of: odoo/odoo#253051
This update fixes a minor typo in the Odoo software's documentation related to country state selection. The 'Departement' word was incorrectly displayed, which has now been corrected. This ensures users receive accurate information and a better experience when setting up their business data.
Original PR description
Fixes #202198 Split from #249963 per reviewer feedback. **CLA sign-off:** Individual CLA signed (doc/cla/individual/vedantmadane.md) Forward-Port-Of: odoo/odoo#253224
This update ensures that follow-up emails sent regarding invoices include the correct invoice PDF attachment. Previously, emails used a generic attachment, which could be unreliable. Now, only the actual invoice PDF is sent, ensuring accurate and complete invoice information is delivered 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#110753 Forward-Port-Of: odoo/enterprise#98820
This update resolves a performance issue where replacing background images could cause the website to hang. The fix replaces a fragile regex-based approach with a more efficient method using CSSOM to remove transform styles, resulting in faster image updates and a smoother user experience. This improves overall website responsiveness.
Original PR description
__Before commit__ Transform-related CSS properties are removed from an image element by manipulating the raw `style` attribute string with a regex which is fragile and costly in performance. __Steps to reproduce (saas-19.2)__ This regex was added in [18.0][1] but is only a real issue since `resetImageTransformation` was called in `on_will_save_media_dialog_handlers` in [saas-19.2][2]: 1. Add a section block. 2. Add a background image. 3. Open the media dialog and replace the background image. => The website will hang for a while. __Fix:__ Use `.style.removeProperty()` instead to speed up the process and to make it less error prone. [1]: https://github.com/odoo/odoo/commit/85698bf4f591fc9280f054b9a255a7d [2]: https://github.com/odoo/odoo/commit/781c0ae77de01f0df8667e0191f6c34 Forward-Port-Of: odoo/odoo#254020 Forward-Port-Of: odoo/odoo#253843
This update restores important VAT checks within the Odoo Enterprise system, which were previously disabled after recent changes. This prevents warnings from appearing when VAT returns are uploaded to Intervat, ensuring accurate reporting and compliance. The changes add a new validation step to guarantee data integrity.
Original PR description
Since the implementation of returns, some VAT checks were no longer being executed. This led to warnings when uploading the XML to Intervat. To catch these issues beforehand, this commit: - Restores the warning checks directly on the report. - Adds a new check on the VAT return that passes only if no warnings are raised. task-5883037 Forward-Port-Of: odoo/enterprise#107152
This update fixes an error in the monthly VAT reports for Italian companies (l10n_it) that resulted in incorrect credit and debit calculations. The fix ensures accurate reporting by correctly handling carryovers from previous periods, specifically addressing issues triggered by VP8 calculations.
Original PR description
The VP14 formulas for both debit and credit were incorrect, leading to wrong values in the monthly VAT report For example, this occurs when there is a carryover from the previous period in VP8 ## Steps to reproduce: - Install l10n_it_reports and switch to the IT company - Create and confirm a Bill (Bill Date: 01/01/2026, Price: 100, Taxes: 10% G) - Create and confirm an Invoice (Invoice Date: 01/02/2026, Price: 200, Taxes: 10%) - Go to Reporting → Tax Report and select Monthly VAT Report (IT) - Select January, then click Returns - Select the period 01/01–31/12 with Monthly periodicity - Review the December and January tax returns by setting all errors to Reviewed, then Validate → Close (to trigger the VP8 carryover) - Return to the report view for February 2026 Check the VP14 credit value: it should be 0 (since the computed amount is negative) opw-6032147 Forward-Port-Of: odoo/odoo#254150
This update resolves an issue where the Point of Sale system in Mexico incorrectly flagged an error when setting an invoice to public for customers without a ZIP code or country. The fix ensures the necessary data is correctly shared with the underlying database, preventing the error and allowing users to properly set invoices to public.
Original PR description
## Issue In the POS of a Mexican company, when requesting an invoice, the user is asked to set the invoice to public or not. If the customer is missing a recognized ZIP code or country, setting the…
## Issue
In the POS of a Mexican company, when requesting an invoice, the user is asked to set the invoice to public or not. If the customer is missing a recognized ZIP code or country, setting the invoice to public **should not** raise an error, but it does. This is because the `l10n_mx_edi_cfdi_to_public` field is not correctly updated in the ORM, which leads to the UserError below being triggered, as `l10n_mx_edi_cfdi_to_public` is always set to `False` if it's not updated by its `_compute` method.
https://github.com/odoo/enterprise/blob/dd89c2c72039c9910cc0a303bca332f4103c08f6/l10n_mx_edi/models/account_move_send.py#L54-L55
## Cause
The said field is not properly updated because it is a *compute field*. Such fields are not transferred to the ORM because of the two following conditions from the POS:
1. https://github.com/odoo/odoo/blob/5c2280d089f248dff67df980bee1ce6a4156f2c9/addons/point_of_sale/static/src/app/models/related_models.js#L205-L206
2. https://github.com/odoo/odoo/blob/5c2280d089f248dff67df980bee1ce6a4156f2c9/addons/point_of_sale/static/src/app/models/related_models.js#L895-L896
## Solution
To minimize behavioral changes, the required field (`l10n_mx_edi_cfdi_to_public`) is simply added at the end of the
serialization process.
Once this field is correctly shared with the ORM, the UserError is not longer raised when the *Invoice to Public* field is set to "Yes" in the POS.
## Versions >= 19.1
Since https://github.com/odoo/odoo/pull/216523, the error would only be displayed **after** moving onto the FeedbackScreen. Since then, the validation is only computed after moving the POS to the next screen.
**To correctly prevent the user from confirming an order with invalid data, we now check the constraints everytime the customer or the invoicing method is updated:**
- If a customer is selected, trying to set *"Invoice to public"* to *"No"*
will raise an error if the user does not have a ZIP code and a country set.
- If *"Invoice to public"* is set to *"No"*, trying to remove the current
customer or select a customer with a missing ZIP code or country will raise an error.
## Steps to reproduce the initial error:
1. Install the following app and module:
- Point of Sale (`point_of_sale`)
- Mexican Localization for the Point of Sale (`l10n_mx_edi_pos`)
2. Set the company to a Mexican one (e.g., *ESCUELA KEMPER URGATE*)
3. Open the POS app
4. Open a register
5. Select a product and click *Add*
6. Click *Payment*
7. Set the Customer to a new customer with only a name
(no Country/ZIP Code)
- Click "Cash" to set the Remaining to 0
8. Toggle the *Invoice* button, set the *Invoice to Public* to *"Yes"* and click *Ok*
9. Click *Validate*.
10. An error *"Invalid Operation, CFDI not set to Public"* appears.
opw-5171035
Forward-Port-Of: odoo/enterprise#101365
Forward-Port-Of: odoo/enterprise#99871This update fixes an issue where orders created through the MPS weren't consistently grouped into single RFQs. The change ensures that date formats are handled correctly, preventing the creation of duplicate RFQs and improving order management. This improves the accuracy of RFQ reporting.
Original PR description
Issue ----- Orders created through the MPS aren't grouped in a single RFQ. Steps to reproduce ----- - Create a product with a vendor - Add it to the MPS with the buy route - Change the forecast to 2…
Issue ----- Orders created through the MPS aren't grouped in a single RFQ. Steps to reproduce ----- - Create a product with a vendor - Add it to the MPS with the buy route - Change the forecast to 2 - Order - Change the forecast to 5 - Order - Go to RFQs > There are 2 different RFQs Cause ----- When doing `_run_buy`, no existing PO is found https://github.com/odoo/odoo/blob/98e3020bcffaf449291d1e6664ba613761f37331/addons/purchase_stock/models/stock_rule.py#L102 so a new one gets created. The reason why the existing PO is not found is because we add `date_planned_mps` to the search domain https://github.com/odoo/enterprise/blob/42102423069c2cebbc01eb4d1d8f9b6215358639/mrp_mps/models/stock_rule.py#L10-L15 However, `values['date_planned']` is a datetime.date, whereas `date_planned_mps` is a datetime.datetime in DB. https://github.com/odoo/enterprise/blob/42102423069c2cebbc01eb4d1d8f9b6215358639/mrp_mps/models/purchase_order.py#L10 This poses some problems with timezones, as the client and db dates might differ. We can avoid the problem by converting the date to datetime. ----- Ticket: opw-5171041 Forward-Port-Of: odoo/enterprise#106968
This update significantly speeds up stock forecasting by optimizing how the system calculates product availability. The change reduces processing time from 90 seconds to just 10 seconds, improving the responsiveness of stock reports. This enhancement is crucial for efficient inventory management.
Original PR description
Before this commit, computing `product_availability` and `product_availability_state` required calling the `get_report_lines` method from the `stock.forecasted_product_product` model. In pickings…
Before this commit, computing `product_availability` and `product_availability_state` required calling the `get_report_lines` method from the `stock.forecasted_product_product` model. In pickings containing moves linked to many incoming and outgoing moves, the `reconcile_out_with_ins` function caused performance issues. The reconciliation logic worked as follows: 1. For each `out_move`, attempt to match it with an `in_move` if the `in_move` references the `out_move` in its `move_dests`. 2. If the demand of the `out_move` is not fully satisfied, add it to `unreconciled_outs`. 3. Loop over `unreconciled_outs` (after attempting to reconcile them using the initial prodcedure) to reconcile against the remaining `in_moves`. The performance bottleneck was that even when an `in_move` directly referenced an `out_move`, the code would unnecessarily loop over **all** `in_moves` to filter out the `in_moves` that has the `out_move` in its `move_dest`. --- To improve performance, an **inverse mapping** from `out_move` IDs to their corresponding `in_moves` is introduced. - Reconciliation now starts by iterating only over the relevant `in_moves`. - If the demand is still unmet, the algorithm attempts reconciliation against the remaining `in_moves`. - This reduces the time complexity to **O(N + M)**, since `in_moves` with zero quantities are removed and never revisited. **Implementation details:** - An `OrderedSet` is used for the inverse mapping to preserve the original query order. - Benefits of `OrderedSet`: - **O(1)** removal (assuming no collisions) - Maintains insertion order, ensuring the same order as the query result. --- | Metric | Before PR | After PR | |---------------|-----------|----------| | Execution Time| ~90 sec | ~10 sec | The benchmark above is done on a `stock.picking` record that queried in the `_get_report_lines` method **5331** `out_moves` and **8922** `in_moves`. opw-4951469 Forward-Port-Of: odoo/odoo#235801 Forward-Port-Of: odoo/odoo#224002
This update corrects a display issue where the CLABE field was appearing twice in the bank account form for Mexican companies. This change stems from a recent update to how bank information is displayed within Odoo. The fix ensures a cleaner and more accurate user experience.
Original PR description
Currently, the CLABE field appears twice in the bank account form for mexican companies. **Steps to reproduce:** - Install the `l10n_mx` module and switch to the `ESCUELA KEMPER URGATE` company. - Go…
Currently, the CLABE field appears twice in the bank account form for mexican companies. **Steps to reproduce:** - Install the `l10n_mx` module and switch to the `ESCUELA KEMPER URGATE` company. - Go to Invoicing > Customers > Customers and open any company partner. - Open the `Invoicing` tab. - For `Banks`, enter any number and click `Create and edit...`. **Observation:** The `CLABE` field is displayed twice in the bank account form. **Root Cause:** In previous versions, Banks were displayed as `lines` in the contact form. However, starting from `saas-18.2`, Banks are displayed as a `regular field with an internal link` that opens the bank form view. After commit [1], the view at [2] indirectly inherits from `base.view_partner_bank_form`, while the view at [3] directly inherits from the same base view. Both views add the field `l10n_mx_edi_clabe`, resulting in the `CLABE` field being displayed twice for Mexican companies. **Fix:** Since removing an XML view is not considered a stable solution, in the stable versions, so we make this field invisible. In the master, removes the redundant inherited view [2]. [1]: https://github.com/odoo/odoo/pull/187357/commits/05575b10d90cedb1ca9910aaa9f1293c3fafdd26 [2]: https://github.com/odoo/odoo/blob/6c0baa2a976eace1f414731d66674243e90664f2/addons/l10n_mx/views/partner_view.xml#L1-L13 [3]: https://github.com/odoo/odoo/blob/6c0baa2a976eace1f414731d66674243e90664f2/addons/l10n_mx/views/res_bank_view.xml#L15-L25 opw-6014799 Forward-Port-Of: odoo/odoo#252963
This update ensures the title of the embedded account report within the annual report correctly reflects the user's selected language. Previously, the title remained in English regardless of the UI language setting. This change improves the user experience by providing localized content.
Original PR description
### Issue before this commit: When generating the annual report, the title of the embedded account report displayed in the table of contents remained in English even when the user interface language was changed. ### Steps to reproduce the issue: 1. Install another language than english and switch to that one 2. Install Accounting app and audit modules 3. Go to Accounting > Revision > Annual Report 4. Create an Annual Report and click on it 5. Index is in the correct language but the title inside is not ### Cause of the issue: The issue occurred because the name property passed to the AccountReportComponent was not translated. Reason to introduce the fix: To translate the embedded account report title according to the user’s current language. opw-5958383 Forward-Port-Of: odoo/enterprise#109962
This update fixes a usability issue on mobile devices where a key button for loan calculations was hidden within a dropdown. The change ensures a smoother, more intuitive experience when creating new loans on mobile, allowing users to easily access necessary features. This improves efficiency and reduces frustration for mobile users.
Original PR description
Forward-Port-Of: odoo/enterprise#110552 Forward-Port-Of: odoo/enterprise#110120
This update ensures that shift emails are automatically sent to employees in their preferred language, regardless of the user's language settings. Previously, emails were defaulted to the current user's language, causing confusion. This fix improves communication and user experience for international teams.
Original PR description
Steps to reproduce: ------------------------- 1. Install Planning and Contacts. 2. Install any language other than English (e.g., Arabic). 3. Change an employee's contact language to that language.…
Steps to reproduce: ------------------------- 1. Install Planning and Contacts. 2. Install any language other than English (e.g., Arabic). 3. Change an employee's contact language to that language. 4. Create a shift for that employee and click "Send". 5. Check the message in Settings > Technical > Discuss > Messages. Issue: --------- The email is sent in the language of the current user rather than the language of the employee receiving the shift. Cause: --------- The mail template rendering logic ([_render_lang](https://github.com/odoo/odoo/blob/0dbfa8b99d5c28a7d84e781a7f23b226fd964e95/addons/mail/models/mail_render_mixin.py#L549-L566)) fails to determine a valid language on the planning slot record because it is not directly linked to a `partner_id`. As a result, it falls back to the current user's language. Solution: ------------ Explicitly pass the employee partner's language in the mail context so that the email is sent in the correct language. opw-5928676 Forward-Port-Of: odoo/enterprise#110778 Forward-Port-Of: odoo/enterprise#109619
This update fixes a technical issue in the Odoo Enterprise software related to demo certificates for Peru (l10n_pe_edi). The certificate's lifespan was extended by ten years to ensure it remains valid for testing purposes. This ensures accurate demonstration of the module's functionality.
Original PR description
In runbot's faketime tests, the test 1 year in the future goes past the end date of the demo PE certificate which had a lifetime of 2017-02-25 to 2027-02-25. This commit replaces that with one that lasts another ten years (2026-03-13 to 2036-03-13). runbot-241058 Forward-Port-Of: odoo/enterprise#110719
This update fixes an issue where refund payments were incorrectly created as 'inbound' instead of 'outbound'. When processing refunds with the 'Identify Customer on the Card' payment method, the system now accurately classifies refund payments, ensuring correct accounting and reporting within the invoicing system. This improves the reliability of financial data.
Original PR description
Step to reproduce: - Install point_of_sale - Enable Identify Customer on the Card payment method - Create an order with a customer and refund it - Use Card as the payment method - Close the POS…
Step to reproduce: - Install point_of_sale - Enable Identify Customer on the Card payment method - Create an order with a customer and refund it - Use Card as the payment method - Close the POS session - Go to Invoicing → Customers → Payments Observation: - Two payment records are created - Both payments have payment_type = inbound - The refund payment should be outbound Cause: - When Identify Customer is enabled, `_create_split_account_payment` is used to create payment records - The method does not adjust payment_type for refund transactions Fix: - Add helpers to swap destination and outstanding accounts - Set `force_outstanding_account_id` instead of `outstanding_account_id`, as the former has priority - Ensure refund payments are created as `outbound` few related fix: https://github.com/odoo/odoo/commit/303a9061da85048f14a3ca7b1e13df0ab34da99e https://github.com/odoo/odoo/commit/718fac6832ecd343bf26d41fa5ae5b1ab74f4228 https://github.com/odoo/odoo/commit/684415b9ff2e151506da561016dbfa991bfa8dc8 opw-5437456 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254079 Forward-Port-Of: odoo/odoo#247760
This update resolves an issue where downpayment products weren't correctly linked to downpayment lines in sales orders. The fix adds the product to the downpayment line during creation, ensuring accurate tracking and settlement of downpayments. This improves the functionality of the POS system.
Original PR description
Step to reproduce - install pos_sale - create a SO (make sure it is in draft) - open pos, make sure it has downpayment product - do a downpayment for that SO - go to backend, open SO Observation: - The downpayment product is not linked to downpayment line Cause: - After refactor [1], downpayment product is not added in sale line [1] https://github.com/odoo/odoo/commit/175daa5db6a3f16be6b636a36e2b8462306b2eb4 Fix: - Added the product when creating downpayment line **Note:** - Actual issue reported was different, and was side effect of this issue - there, the downpayment was not considered when trying to settle SO from pos opw-5934461 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250548
This update resolves an issue where users couldn't select 'Other Expenses' as an option for expense accounts when creating loans. This change expands the flexibility for accurately categorizing loan expenses, ensuring a more complete and precise record of financial transactions. It improves the usability of the loan management feature.
Original PR description
Allow accounts with the "Other Expenses" type to be selected in the Expense Account field of Loans. task-5946452 Forward-Port-Of: odoo/enterprise#110085
This update resolves an issue that prevented the system from correctly handling KSeF (Polish eInvoice) rate limits. Previously, a technical error occurred when the system reached its request limit, causing a crash. This fix ensures the system gracefully handles rate limits and prevents errors, maintaining reliable invoice processing for Polish businesses.
Original PR description
Before this commit: Steps 1. Create a Polish company 2. Run scheduled action "Polish eInvoice: Download vendor bills from KSeF" 3. If the customer gets 429 Too Many Requests => A traceback error is raised as message isn't an attribute in KSeFRateLimitError object `AttributeError: 'KSeFRateLimitError' object has no attribute 'message'` This happens because `KSeFRateLimitError` does not define a `message` attribute. The message is only passed to the base Exception and stored in `args`. After this commit: Use `str(e)` to properly retrieve the exception message and avoid the AttributeError. opw-6009380 Forward-Port-Of: odoo/odoo#253549
This update resolves an issue where the icon toolbar was unexpectedly appearing in the To-Do module when creating a Table of Contents. The fix removes a redundant check within the HTML editor that triggered this behavior, ensuring a smoother user experience. This improves usability and prevents unnecessary visual clutter.
Original PR description
Steps to Reproduce: - Go to To-Do. - Inside a list, insert a Table of Contents. - Click at the top, outside of the Table of Contents. Description of the issue - The icon toolbar appears unnecessarily. Cause: - This happens because the `icon_plugin` checks whether a node’s child contains an icon and, if so, displays the icon toolbar. Although the Table of Contents contains an icon, this condition passes, causing the toolbar to appear. - The same issue can occur with other elements that contain an icon. For example pressing enter before a star element also opens the icon toolbar. Solution: - Remove the condition that checks whether a node’s child contains an icon. task-5954459 Forward-Port-Of: odoo/odoo#250918
This update enhances the PEPPOL integration by providing more detailed error messages. Previously, messages were solely based on error codes, making debugging difficult. Now, the system captures and displays the full server error, simplifying troubleshooting and improving the client experience. This change addresses a key issue identified in Schematron validation.
Original PR description
Before this commit, all messages where mapped based on the error code and not from the server error. Schematron/XSD issues really need the full error to make easy for debugging/client. OPW-5980046 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252252
This update resolves a technical issue that was causing test failures in the point-of-sale preparation display module. The trigger that checked for a spinning icon (fa-spin) was removed because it was incorrectly reacting to minor delays, which has now been addressed. This ensures the display functions reliably.
Original PR description
In this commit: = - Removed the trigger that checks for `fa-spin` as it was causing test failures when minor delays occurred between steps. - Checks for `fa-spin(Sync)` is alredy handled by the `isSynced` or `waitRequest`. Runbot-error: [198580](https://runbot.odoo.com/odoo/error/198580), [234025](https://runbot.odoo.com/odoo/error/234025) Forward-Port-Of: odoo/enterprise#87281
This update ensures that the 'File' constructor in Odoo correctly receives the MIME type of uploaded files, aligning with modern web standards. This change improves compatibility with older Chrome versions and ensures files are handled properly across different browsers, preventing potential display or functionality issues.
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#254154 Forward-Port-Of: odoo/odoo#253631
This update ensures Odoo correctly handles file types when creating files, aligning with modern web browser standards. Specifically, it fixes an issue where file types weren't being properly transmitted, which could cause compatibility problems with older versions of Chrome. This ensures consistent 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/enterprise#110812 Forward-Port-Of: odoo/enterprise#110496
This update corrects a misconfiguration in the Hungarian tax settings. Previously, the 0% EU Goods Intra-community tax was incorrectly linked to external partners. This change ensures the tax is accurately linked to EU partners, aligning with Hungarian tax regulations and improving reporting accuracy.
Original PR description
In Hungary, the 0% Goods Intra-community tax is mapped with the EU partner & Partner outside the EU, which doesn't make sense. Intra-community taxes should only be mapped with the EU partner fiscal position. This commit removes the outside EU position from this task. no-task Forward-Port-Of: odoo/odoo#253526
This update fixes an issue where cancelled vendor bills were incorrectly included in the Sweden accounting SIE export. The fix ensures that cancelled transactions are properly excluded, aligning the export with the general ledger and providing accurate reporting. This prevents discrepancies in financial data.
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#110612 Forward-Port-Of: odoo/enterprise#108767
This update resolves an issue where the copyright background color wouldn't apply correctly when the footer had no background color. The fix adds a fallback value to the CSS, ensuring the copyright color displays as intended regardless of the footer's background setting. This improves the visual consistency of the website.
Original PR description
Before this commit, a css error would happen when the user tried to change the copyright background color if the footer had no background color.
This was due to $-footer-color not having a fallback value when neither o-color('footer-custom') nor o-color('footer') was defined.
This commit adds a fallback value to fix the issue.
task-5452457
Forward-Port-Of: odoo/odoo#248283This update significantly speeds up Odoo's email processing, particularly when handling large volumes of records. The change optimizes how email messages are grouped, reducing processing time by a substantial margin. This results in faster email sending and receiving, improving overall system responsiveness.
Original PR description
opw-5969596 Replace per-record recordset concatenation in _mail_group_by_operation_for_mail_message_operation with an id-first aggregation strategy. Collect ids per access operation, then browse once per operation and restore prefetch. This avoids repeated recordset additions in a loop, which are expensive on large batches. | No. records | Before | After | |------------|--------|-------| | 57,725 | 9,351.744 ms | 143.174 ms | | 1,122 | 4.563 ms | 2.732 ms | | 2,093 | 11.194 ms | 2.747 ms | Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253048
This update resolves an issue where users with dark mode enabled in their browsers (like Brave) experienced usability problems with our point-of-sale and self-order systems. A simple change – adding a meta tag – prevents the browser from overriding our website's colors, ensuring a smooth experience for all customers.
Original PR description
Users who have enabled the dark mode option in Brave that automatically modifies website colors may experience usability issues with the self-order and point_of faile. To avoid this, a meta tag has been added to disable Dark Reader modifications . Task.6037294 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253892
This update addresses a bug where a caption remained on the HTML editor after replacing an image with another media type. The fix ensures that the caption is automatically removed when an image is replaced, preventing errors and improving the user experience. This ensures consistent behavior and avoids unexpected issues when users modify their content.
Original PR description
**Current behavior before PR:** Steps to reproduce: - Add a caption on an image - Click on image - Replace image by an icon using replace option from Toolbar - Putting cursor on caption input and clicking anywhere outside editable leads to traceback. This happens because after replacing image with an icon, caption is still there but there is no image inside caption. As result, in `cleanForSave` accessing image leads to traceback. **Desired behavior after PR is merged:** Now, if image is replaced by any other media than image, caption is removed. task-5950977 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253723 Forward-Port-Of: odoo/odoo#249452
This update fixes an issue where manually adjusted prices in point-of-sale (POS) settlements weren't being correctly applied. Previously, when settling a quotation, prices were automatically reverted to the base price, regardless of user-defined changes. Now, the system accurately reflects the user's manually set prices during settlement.
Original PR description
**Steps to reproduce:** - Create a product tracked by lot, set it's price to 1000 - Create a quotation add a line with the created product and change the price to 1200 - Add another line with the…
**Steps to reproduce:** - Create a product tracked by lot, set it's price to 1000 - Create a quotation add a line with the created product and change the price to 1200 - Add another line with the same product and change it's price to 600 - Go to PoS and settle this quotation - The lines' prices will be 1000 and 600 instead of 1200 and 600 **Why the fix:** In the event of a settle with a product tracked by lots, we are setting the price of all *related_lines* (lines with the same product in this case) to it's base price, not taking into account the fact that this price has been modified by the user when making the quotation. This only happens for related lines, which explains why one line's price is still 600 while the other was reverted to the base price of 1000 instead of being 1200 as it was previously set. To avoid this, we now set the price_unit back to the base one only if the price hasn't been changed manually. opw-5223463 Forward-Port-Of: odoo/odoo#252480 Forward-Port-Of: odoo/odoo#238295
This update resolves an issue where clicking 'View' links after deleting a website page (like 'ContactUs') didn't function correctly. The fix ensures that links now accurately direct users to the correct records, improving the user experience and preventing navigation errors. This was a minor bug related to how URLs were constructed.
Original PR description
**Steps to reproduce:** 1. Go to the list view of website pages. 2. Select the page "ContactUs". 3. Click Delete. 4. A warning dialog appears. 5. Unfold one of the lists of records where the page is used. **Issue** Clicking on a record link (for example, "View") does not redirect anywhere. This is due to the use of the model display name in url. caused by https://github.com/odoo/odoo/commit/de302c2d36305c0d7562572a30587641eabfe914 **Fix** Use the model_name instead of the display name in the URL. task-5880458 Forward-Port-Of: odoo/odoo#245932
This update fixes an issue where the Gemini AI occasionally returned empty responses to users, creating a blank screen. The change implements a retry mechanism with increased budget attempts, ensuring a response is always delivered. This improves the user experience by preventing perceived errors when the AI is temporarily unavailable.
Original PR description
It often occurs that gemini responses come back empty without anything to show to the users. Specifically, the response object has content but the "parts" are empty - the place were you either get a function call or a message to the user by the LLM. Prior to this commit, when this occured, we didn't perform any explicit handling. We would always just return what the LLM responded with, which when empty would be nothing. UX wise, it would seem like something broke because the user would basically get no reply. In this commit, we add a retry mechanism in `_request_llm_google` of `llm_api_service.py`, where if we get no response, we increase the thinking budget of the next request and try again. After 3 unsuccessful tries, we send a failure response to the user. Task-5959805
This update resolves a technical issue preventing users from successfully interacting with the AI when viewing documents through the file viewer. The problem stemmed from a negative file ID used by the AI, which was intentionally set by the documents team to prevent data reloading. The fix ensures the AI correctly identifies and processes document attachments.
Original PR description
Before this commit, whenever a user tried to interact with the ai regarding a document opened in the file viewer, they would get a traceback with a 404 error. This was caused by the file id that we passed in the `openAIChat` method of the `AIChatLauncher` service. The id is negative on purpose by the documents team - there is a comment stating that it "prevents a reload from resolving to a real record". On the AI side, when using the id to search for the attachment to send to the AI, we get an error because the id is negative. This bubbles up to the user. We fix this by replacing the `this.file.id` with the `this.file.documentId` which holds the same value - just not-negative. Task-6030598
This update resolves an issue where scanning a packaging barcode didn't correctly associate with the related lot, leading to incorrect inventory tracking. The fix ensures that packaging barcodes are properly linked to lots during scanning, improving the accuracy of stock management.
Original PR description
When scaning a lot after a packaging, the lot won't recognize the packaging and will not work properly ### Steps to reproduce: * In the settings enable packagings * Create a storable product P with…
When scaning a lot after a packaging, the lot won't recognize the packaging and will not work properly ### Steps to reproduce: * In the settings enable packagings * Create a storable product P with Units as uom, a barcode and tracked by lots * Create new lots with barcode for Product P * Inventory > Configuration > Product > Units & Packagings * Click on pack of 6 > Packaging Barcodes > New * Create one for your product with a different barcode * Go to barcode > Operations > eg. internal transfer > New * Scan packaging barcode * Scan one of the lots -> Issue, the lot create a new line, and will not find the packaging ### Observation: When scanning a barcode, it will first try to find a match with existing lines, In our case, it will find a match with the line of the packaging, but since the line is considered as "completed" since there was no expected quantity since we create a new picking: https://github.com/odoo/enterprise/blob/13d815457d47846d5391c9a2dc1ed244ef64b6c4/stock_barcode/static/src/models/barcode_picking_model.js#L1497-L1501 It will erase the line, to avoid to overfill a completed line: https://github.com/odoo/enterprise/blob/13d815457d47846d5391c9a2dc1ed244ef64b6c4/stock_barcode/static/src/models/barcode_model.js#L1459-L1460 and since, it decided to ignore that line, it will not find another lines, and will create a new one : https://github.com/odoo/enterprise/blob/13d815457d47846d5391c9a2dc1ed244ef64b6c4/stock_barcode/static/src/models/barcode_model.js#L1535 Additional Issues ----------------- Issue 1 : When scaning a packaging, lot1, packaging, lot2, all the packagings will be linked to the first lot, which doesn't allow us to scan multiple lots. Issue 2 : When having sublines with different uoms, it will add the quantity without considering the differences in uoms ### Steps to reproduce: * In the settings enable packagings * Create a storable product P with Units as uom, a barcode and tracked by lots * Create new lots with barcode for Product P * Inventory > Configuration > Product > Units & Packagings * Click on pack of 6 > Packaging Barcodes > New * Create one for your product with a different barcode * Create a packaging 2 with barcode for product A * Go to barcode > Operations > eg. internal transfer > New * Scan packaging 1 barcode * Scan one of the lot 1 * Scan packaging 1 * Scan lot 2 -> Issue 1, the packaging 2 will be link to lot 1, it won't be possible to link any packaging to another lot. * Scan packaging 2 -> Issue 2, it create a subline (excpeted), but the sum that appear on the main grouped line is wrong, it doesn't considere the difference in uoms ### Observation: Issue one : When scanning a barcode, it will first try to find a match with existing lines, since the uom is the same it will not be erased by the full line check https://github.com/odoo/enterprise/blob/13d815457d47846d5391c9a2dc1ed244ef64b6c4/stock_barcode/static/src/models/barcode_model.js#L1456-L1460 and since, it found a line, it will just add it's self to the line Issue Two: When creating the group lines it will first calculate the sum of all the quantities: https://github.com/odoo/enterprise/blob/8774388a7b1b2ca2c08c752026ac1a20dbc10347/stock_barcode/static/src/models/barcode_model.js#L248-L254 And after inside of groupSublines it will choose the main line and it's uom and use the previous sum for the total quantity: https://github.com/odoo/enterprise/blob/8774388a7b1b2ca2c08c752026ac1a20dbc10347/stock_barcode/static/src/models/barcode_picking_model.js#L1456-L1461 opw-5189492 opw-5408372 Forward-Port-Of: odoo/enterprise#108666 Forward-Port-Of: odoo/enterprise#98701
This update fixes a bug where invoices could be created for timesheets that had already been billed, leading to incorrect financial reporting. The change prevents the system from generating new invoices for timesheets that have been previously invoiced, ensuring accurate billing and financial data. It addresses a critical issue related to timesheet invoicing accuracy.
Original PR description
__ ## Short functional explanation of the error When we create an invoice for a quotation that holds a timesheet product and recorded timesheets for last month. In the wizard, we set the timesheet…
__ ## Short functional explanation of the error When we create an invoice for a quotation that holds a timesheet product and recorded timesheets for last month. In the wizard, we set the timesheet period from the first to the last day of last month. Then, we set the `Invoicing Switch Threshold` to the day of last month. We record another hour for the timesheet, for this product, for today. When we select last month as timesheet period when creating a new invoice, the 2 hours that have already been invoiced are reinvoiced. Moreover, once we confirm this second invoice, it is possible to create again and again invoices for these already invoiced timesheets, without changing the Invoicing Switch Threshold parameter. ## Reproduction Steps 1. Create a quotation. Add as a line a timesheet product. Set the quantity to 2. Validate and click on the smart button Recorded. 2. Record 2 hours with a random date for last month. 3. Create an invoice. In the wizard, set the timesheet period to the first -> the last day of last month. Confirm, and on the invoice form, set the invoice date to last month (after the day on which you recorded the timesheet hours) and confirm. 4. Click on configuration > settings. Search for Invoicing Switch Threshold, and set the date to the last day of last month. 5. Go back to the invoice you created. It should have the ribbon `Ìnvoicing App Legacy`. 6. Go back to the sales order. Click on the smart button Recorded and add one more hour to the timesheets, but this time in February. 7. Create an invoice. On the wizard, set the timesheet period to the first -> last day of last month. Click confirm. ### Expected behavior The system shouldn't let us create an invoice, as we have nothing to invoice, as all the timesheets have already been invoiced. ### Unexpected behavior An invoice is created with 2 hours. It doesn't take into account the hours added in February (normal) but reinvoices the timesheets that have already been invoiced (not normal). ## Origin of the issue When retrieving the quantities to invoice for the timesheets, we don't take into account the quantities already invoiced for the same timesheet. __ opw-5426434 Forward-Port-Of: odoo/odoo#250946
This update fixes an issue where creating users for employees with identical email addresses would cause an error. Now, the system will display a warning instead, allowing users to create multiple employees with the same email without disrupting the system. This improves user experience and data integrity.
Original PR description
Creating users for multiple employees sharing the same email address raises a traceback.
Stpes to reproduce the error:
- Install the ``hr`` module
- Create two employees with the same email
- Go to List view of employees > Select both employees > Actions > Create user
Traceback:
```py
ValueError: UniqueViolation('duplicate key value violates unique constraint "res_users_login_key"
```
https://github.com/odoo/odoo/blob/0bfd2a253781e43b0e0d16b3fd9d1df485f4fa6b/addons/hr/models/hr_employee.py#L389
The error occurs because the same email is used as the login for multiple users.
This commit ensures that when multiple employees share the same email address,
a warning notification is displayed instead of raising an error.
sentry-7324335174
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#253258Documentation and clarification updates
This pull request formally welcomes Edilianny Sánchez (edy1192) as a contributor to Vauxoo, a key component of Odoo. This update ensures proper legal and licensing compliance, reflecting Edilianny's contributions to the project. It's a standard process for onboarding new developers.
Original PR description
Incorporate Edilianny Sánchez (edy1192) as Vauxoo's contributor. I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252369
This update ensures our company's CLA (Contributor License Agreement) is current, reflecting the latest employees and accurately represents our legal relationship with Odoo. This ensures compliance and protects both our organization and Odoo's open-source project. The change primarily updates documentation related to the CLA.
Original PR description
Description of the issue/feature this PR addresses: It makes our company CLA up to date with the reality Current behavior before PR: Our company CLA had some old employees in it, and didn't have some new ones Desired behavior after PR is merged: Our company CLA is up to date. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230333