Daily updates from Odoo
Wednesday, March 18, 2026
335 changes
13 changes
Enhancements to existing features
This update improves the Odoo Powerbox search functionality. Users can now find and utilize ‘divider’ or ‘line’ commands directly within the search, making it easier to format content. This enhancement streamlines content creation workflows.
Original PR description
#### Desired behavior after PR is merged: - Separator command now appears when searching for “divider” or “line” in the powerbox. task-5977288 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253168 Forward-Port-Of: odoo/odoo#250935
This update enhances our testing process by allowing developers to easily specify the Chrome or Chromium browser version used during tests. This is primarily to quickly address browser-specific issues and ensure compatibility across different versions, leading to more stable releases. It's a small change that improves our debugging capabilities.
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
Resolved issues and error corrections
This update resolves an issue where downpayment products weren't correctly linked to downpayment lines in sales orders. The fix ensures that downpayment products are properly added when a downpayment is made, addressing a previous reporting problem related to settlement processing. This improves the accuracy of sales order data.
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 within the Loan module. This change now allows for greater flexibility in categorizing loan-related expenses, ensuring accurate financial reporting. It's a minor fix improving usability within the Enterprise suite.
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
A recent change in required field validation caused an error when starting a new pay run in the Hong Kong payroll module. This update ensures that date fields are validated before the system attempts to process them, resolving the 'value.toFormat is not a function' error. This prevents users from being unable to initiate pay runs.
Original PR description
Currently, an error occurs when a user starts a new pay run. Steps to Reproduce: - Install `l10n_hk_hr_payroll_empf` module with demo data. - Switch to the `Hong Kong` company. - Go to `Payroll` >…
Currently, an error occurs when a user starts a new pay run. Steps to Reproduce: - Install `l10n_hk_hr_payroll_empf` module with demo data. - Switch to the `Hong Kong` company. - Go to `Payroll` > `Payslips` > `Pay Runs`. - Click `New`, remove the `period value`, and click `Continue`. `TypeError: value.toFormat is not a function` After this recent [commit] that changed the required field validation behavior, when the date field is empty and it attempts to serialize the date [1], which raises the error here [2]. Although the start and end date field is required, the ORM call is executed without the value for the date field. This commit ensures that, similar to the base PayslipBatchFormController [3], the fields are validated before making the ORM call. [commit]: https://github.com/odoo/enterprise/commit/cd0f5f31e9427cb96092671bbcbb52dfbb3c03f8 [1]- https://github.com/odoo/enterprise/blob/431d1b513f26188f693abd949f78a893514205f0/l10n_hk_hr_payroll_empf/static/src/views/payslip_run_form/hr_payslip_run_form.js#L13-L14 [2]: https://github.com/odoo/odoo/blob/3263a7f54948d57f13176cf0416b1419150e9d87/addons/web/static/src/core/l10n/dates.js#L536 [3]: https://github.com/odoo/enterprise/blob/431d1b513f26188f693abd949f78a893514205f0/hr_payroll/static/src/views/payslip_run_form/hr_payslip_run_form.js#L16-L20 sentry-7207509338 Forward-Port-Of: odoo/enterprise#108885
This update fixes a minor issue where the dynamic snippet carousel wasn't displaying correctly when showing a small number of items. The fix ensures a smoother, more consistent scrolling experience, particularly when the carousel contains fewer items than the visible slide slots. This improves the overall presentation of product listings.
Original PR description
Steps to reproduce: 1. Add a Dynamic Snippet Carousel(Products). 2. Set the number of records to 4. 3. Enable Single Scroll mode. Issue: When a dynamic snippet carousel is in single scroll mode…
Steps to reproduce: 1. Add a Dynamic Snippet Carousel(Products). 2. Set the number of records to 4. 3. Enable Single Scroll mode. Issue: When a dynamic snippet carousel is in single scroll mode (`o_carousel_multi_items`) and the number of fetched items is less than or equal to the visible slots per slide (`chunkSize`, typically 4 on desktop), the carousel still slides one item at a time. Cause: When `scrollMode` is single, the QWeb template generates each data item in its own `carousel-item` div. So with 3 products and 4 visible slots, we got 3 separate slides(this is the usual behavior of single scroll mode). But due to this bootstrap would slide between them one by one. Fix: If the number of fetched records is less than or equal to the number of elements per slide (chunkSize), use "all" scroll mode so that all items are grouped in a single slide instead of being split into individual carousel-items (which would cause unwanted sliding). Forward-Port-Of: odoo/odoo#251916 Forward-Port-Of: odoo/odoo#251700
This update resolves a technical issue that prevented the automated download of vendor invoices from the Polish KSeF system when rate limits were exceeded. The fix ensures the system handles these rate limit errors gracefully, preventing errors and allowing the scheduled action to continue functioning correctly. This improves the reliability of the Polish e-invoicing process.
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 inserting 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 overall usability and prevents unnecessary distractions.
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 way error messages are handled within the Odoo account_peppol module. Previously, messages were based solely on error codes, making debugging difficult. Now, the system captures and uses the full server error, providing more detailed information for troubleshooting and improving client support.
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 fixes an issue where the time slot selection popup stretched unnecessarily across the screen, creating empty space. By adjusting the popup's size to fit its content, the design is now cleaner and more user-friendly. This improves the overall visual experience for users.
Original PR description
The o_modal_full class forces height: 100% on modal-content and modal-body, causing the time slot selection popup to stretch to full screen with empty white space below the content. Override height and top on modal-content and modal-body to let the dialog shrink to fit its content while staying anchored at the bottom of the screen. task-id: 5952769 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a test failure caused by an overly sensitive check for loading indicators (fa-spin). The trigger has been removed, ensuring that minor delays in the system don't incorrectly flag test failures. This improves the stability and reliability of the POS Restaurant Preparation display.
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 fixes a bug where the product search bar didn't function correctly on mobile devices. The issue was due to a missing configuration in the search template, which prevented the search from executing. The fix ensures that product searches work as expected across all device views, improving the user experience for mobile shoppers.
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#254221 Forward-Port-Of: odoo/odoo#251694
This update ensures that the 'File' constructor in Odoo correctly receives the MIME type of uploaded files. This change aligns with Chrome's latest standards, improving compatibility and preventing issues with older browser versions. It's a technical fix to ensure proper file handling.
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
39 changes
Enhancements to existing features
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 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
Documentation 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
12 changes
Resolved issues and error corrections
This update resolves an issue where users couldn't select 'Other Expenses' as a valid account type when creating loan expense records. This change expands the flexibility for accurately categorizing expenses within the loan system, ensuring more precise financial reporting. It's a simple fix that improves data accuracy.
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 a technical issue that caused a traceback during horizontal autofilling of pivot table row headers. While the core functionality remains unchanged, the fix ensures a more stable and predictable experience for users working with pivot tables. The underlying result isn't corrected, but the error is now handled consistently.
Original PR description
When autofilling a positional pivot row header horizontally, we would get a traceback because we were calling `_autofillPivotColHeader` instead of `_autofillPivotRowHeader`. Note that this fix only fixes the traceback, the result is not correct, but is consistent with autofilling a positional col header vertically. Task: [5909266](https://www.odoo.com/odoo/2328/tasks/5909266) Forward-Port-Of: odoo/enterprise#110521 Forward-Port-Of: odoo/enterprise#109620
This update resolves an issue where users were receiving an error message when exporting payroll data to SDWorx for freelance employees. The fix ensures that the system correctly skips the SDWorx code validation step for freelancers, streamlining the export process and preventing unnecessary errors.
Original PR description
Steps to reproduce: ------------------------------- 1. Install `l10n_be_hr_payroll_sd_worx` module 2. Switch the active company to a Belgian company 3. Go to Employees and create a new employee. Set the Employee Type to Freelancer from HR Settings page. 4. Navigate to Payroll > Reporting > Export Work Entries to SDWorx Observation: ------------------------------- A user error is raised stating: ``` There is no SDWorx code defined for the following employees ``` Issue: ------------------------------- The filter checking for missing SDWorx codes did not exclude employees with the Freelance employee type. SDWorx code does not passed to the freelancers Solution: ------------------------------- Add a condition to the employee filter to exclude freelance employees from the SDWorx code validation. opw-5387342 Forward-Port-Of: odoo/enterprise#102211
This update fixes a potential error that occurred when users attempted to check the status of bulk payments not connected to a bank. A new user message has been added to guide users to ensure their payment journal is properly linked to a bank account, preventing the system from crashing.
Original PR description
This commit: https://github.com/odoo/enterprise/commit/c9cc89f58f7d98396afac3bdacfeff9b00a02a21 introduce the initiate bulk payments feature. When selecting a batch you can also check the status of this batch. But for the moment, if you select a batch that is not connected to a bank, the action will traceback with a redirect. This commit will add a user error to warn the user than the journal needs to be connected to a bank. task-6009083 Forward-Port-Of: odoo/enterprise#110474 Forward-Port-Of: odoo/enterprise#109956
This update corrects a technical issue where archived partner data was incorrectly being used when automatically detecting bank statements. Now, the system only retrieves bank statements from active partners, ensuring accurate data and preventing potential errors in financial reporting. This improves data integrity and reliability.
Original PR description
Description of the issue this commit addresses: Partner auto-detection on statement lines could match archived partners via SQL causing unexpected partner_id assignment. Desired behavior after this commit is merged: Partner retrieval from bank account, partner name, and previous statement lines only considers active partners, preventing archived matches. runbot-238918 Forward-Port-Of: odoo/enterprise#110446
This update resolves a test failure caused by overly sensitive checks for loading indicators (fa-spin). The change removes a specific trigger that was incorrectly reacting to minor delays, ensuring smoother and more reliable test execution. This improves the stability of the restaurant preparation display feature.
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 Odoo correctly handles file types, particularly when used with older versions of Chrome. The change corrects a technical issue related to MIME types, aligning with web standards and improving compatibility 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 fixes a potential error in our delivery processing system. Sometimes, Sendcloud, a shipping provider, doesn't respond when requested, causing a system error. This change prevents the system from crashing when a response isn't received, ensuring smoother delivery processing.
Original PR description
Sendcloud sometimes doesn't respod when asking for `shipping-price`. So when we try to retrieve the first element of the response, we raise an `IndexError`. ----- Ticket: opw-5951749 Forward-Port-Of: odoo/enterprise#109252
This update fixes a bug where project timesheets didn't accurately reflect labor costs when changing the employee assigned to a manufacturing order. The fix automatically updates the AAL (analytic accounting line) linked to the work center, ensuring accurate timesheet calculations and reporting. This ensures project costs are correctly tracked.
Original PR description
### Steps to reproduce: - Create an MTO product and another Service product that create a project and task - Create a quotation with both products - Create two employees with different hourly cost - Go to Manufacturing order - Configure an employee to manufacture the product at a work station. - Observe the project dashboard - Go back to the MO and change the employee on the work station - Notice the project dashboard Timesheets section doesn't have any change on the amount ### Cause: This is happening because when changing the employee we don't modify anything in the AAL linked to the work station. As we only modify the AAL when the duration change. ### Fix: We call _create_analytic_entry when we change the employee on the work station to change the amount and the employee_id for the AAL. opw-5939321 Forward-Port-Of: odoo/enterprise#109695
This update fixes a problem causing incorrect stock synchronization for Amazon listings, leading to phantom orders. The fix allows users to manually specify the fulfillment channel (FBA or FBM) for listings, resolving a known Amazon issue and improving order accuracy. This ensures correct inventory management and prevents revenue loss.
Original PR description
When configuring a listing on Amazon Seller Central, the user must choose **one** of the available fulfillment channels that Amazon offers. We distinguish two kinds: Fulfillment by Amazon (FBA) and…
When configuring a listing on Amazon Seller Central, the user must choose **one** of the available fulfillment channels that Amazon offers. We distinguish two kinds: Fulfillment by Amazon (FBA) and Fulfillment by Merchant (FBM). However, Amazon suffers from a known issue of ghost listings. A ghost listing occurs when an offer is presumably sold via FBA, but in fact stores stock information for both FBM and FBA creating unwanted FBM orders. To avoid ghost listings, the first solution was to disable stock synchronization as soon as an offer contained stock in the Amazon location of Odoo. However, if a merchant decided to change the fulfillment channel, it became impossible to sync the stock anymore. See also e7c01c7097d90e731c5408cee4d3595ed810c8fa. To resolve this issue, we decided to use the Amazon API to fetch information about the fulfillment channel of a listing. However, Amazon doesn't give a clear answer for a given listing. Therefore, after some research, the assumption was that an offer was FBM if the listing contained a `merchant_shipping_group`, as the merchant shipping group is a setting specific to FBM listings. See also e6d620e4b200cadabb00ce37ab03289cfeb4ae58. However, this assumption was flawed because Amazon can keep the shipping group even if the listing switches to FBA. This in turn enabled stock synchronization, leading to ghost listings. To fix this issue we give the possibility to users to manually set the correct fulfillment channel of an offer when it becomes ambiguous. opw-5480254 See also: - https://github.com/odoo/upgrade/pull/9692 Forward-Port-Of: odoo/enterprise#106662
This update resolves a technical issue that caused a traceback when reconciling multiple journal entries. The fix skips a calculation step in the reporting process when multiple reconciled lines are present, ensuring accurate reporting. This improves the stability of the accounting module.
Original PR description
**Steps to reproduce:** - Install Accounting - From a Bank journal, create a transaction with an amount of -1000 - Set Account to "Liquidity Transfer" - From a Cash journal, create a transaction with…
**Steps to reproduce:** - Install Accounting - From a Bank journal, create a transaction with an amount of -1000 - Set Account to "Liquidity Transfer" - From a Cash journal, create a transaction with an amount of 999.99 - Set Account to "Liquidity Transfer" - Create a MISC entry: | Account | Debit | Credit | | -------------------- | ----- | ------ | | Liquidity Transfer | 0.00 | 0.01 | | Cash Difference Gain | 0.01 | 0.00 | - Post the entry - From Journal Items list, group by Account, select the 3 lines on "Liquidity Transfer" account and reconcile them - Go back to the Bank journal and try to edit the previous transaction **Issue:** A traceback is raised. **Cause:** In "_compute_full_amount_switch_html" method, the reconciled lines linked the current line are retrieved. A single line is expected and some operations that are only allowed on a singleton are performed. In our case, the reconciliation has been performed manually and there are several reconciled lines ; which violates the singleton condition. **Solution:** The value computed by "_compute_full_amount_switch_html" has no sense if there's more than one reconciled line. Therefore, the computation can be skipped in such a case. opw-6031879 Forward-Port-Of: odoo/enterprise#110857
This update fixes a problem causing users to receive duplicate push notifications from Social Marketing. The fix ensures the Firebase SDK and service worker work together correctly, preventing redundant popup displays. It also resolves a subscription error, improving push notification reliability across browsers.
Original PR description
When the user sends a push notification through Social Marketing, the application displays two notification popups because: 1. The Firebase SDK automatically displays a notification popup if the…
When the user sends a push notification through Social Marketing, the application displays two notification popups because: 1. The Firebase SDK automatically displays a notification popup if the request made to Firebase includes a `notification` field. 2. Our service worker displays a notification popup when receiving a background message from Firebase. To prevent duplicate notifications, we will remove the custom event listeners in the service worker and update the request made to Firebase so that the Firebase SDK opens a notification for us. Furthermore, this PR fixes the error `Failed to execute 'subscribe' on 'PushManager': Subscription failed - no active Service Worker` occurring when the user accepts the push notifications. To fix that issue, we will: 1. Ensure that the service worker reaches the `ready` state before communicating with it. 2. Set the service worker's scope to `/` so it controls all pages on the origin, ensuring push subscriptions succeed and the worker can communicate with any page. Finally, we will use the legacy `importScripts` syntax to load Firebase dependencies because the ECMAScript module syntax is not supported for service workers in Firefox. This approach improves push notification compatibility across browsers. Task-5124645 Forward-Port-Of: odoo/enterprise#110823 Forward-Port-Of: odoo/enterprise#96029
16 changes
Enhancements to existing features
This update enhances our testing process by allowing developers to easily specify the Chrome/Chromium browser version used during tests. This enables quicker identification and resolution of browser-specific issues, leading to more stable and reliable software releases. It's a key improvement for debugging and preventing disruptions.
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
Resolved issues and error corrections
This update resolves a potential error that occurred when loading demo data in the pos_loyalty module. The change prevents errors if referenced records aren't found during the loading process, ensuring demo data can be loaded consistently even with interruptions or concurrent uninstallations.
Original PR description
Currently, an error may occur if a referenced record ID is not found during XML data loading. This can happen in various scenarios, including:
- While loading demo data during module installation.
- When an exception interrupts demo data loading, it prevents remaining data from being processed.
- When demo data is being loaded while the module is simultaneously being uninstalled in another session.
**Steps to Reproduce:**
- Install all the modules without demo data.
- Go to settings and manually load the demo data.
- If a user error occurs during this process, the demo data load will fail and raise an error.
**Error:**
`Could not eval([(4, ref('mrp.product_product_computer_desk'))]) for product_ids in {"lang":null}`
This commit applies `raise_if_not_found=False` to XML references in `eval`, preventing errors when the referenced external ids are missing.
Related-enterprise-PR: https://github.com/odoo/enterprise/pull/86681
Sentry - 3935871751This update resolves an issue where validating a delivery record would cause an error when the associated sale order lacked order lines. The fix automatically assigns a default sequence value of zero, ensuring deliveries can be validated correctly even without existing order lines. This improves the reliability of the delivery process.
Original PR description
Currently, an error occurs when user validates a picking. **Steps to Reproduce:** - Install the `sale_management` and `sale_stock` modules. - Create a `sale order` without `any sale order lines` and…
Currently, an error occurs when user validates a picking. **Steps to Reproduce:** - Install the `sale_management` and `sale_stock` modules. - Create a `sale order` without `any sale order lines` and `confirm` it. - Go to `Inventory > Operations > Deliveries` and create a `picking record by adding a move line` with a `quantity` greater than `zero`. - In the `Additional tab`, select the `sale order (the one without order lines)`. - Now `validate` this delivery. **Error:** `ValueError: max() arg is an empty sequence` This error occurs because, during validation of the delivery record, the system attempts to `create a sale order line` for the product. If the sale order does not have any `existing order lines`, the system tries to determine the `sequence` from existing sale order lines. Since `no lines exist`, the `sequence list is empty` [1], raising the error. This commit ensures that when a sale order has no existing order lines, a default sequence value of zero is used. [1]- https://github.com/odoo/odoo/blob/9e404b52e8c9375a6534a67cfb0fcc0df523402b/addons/sale_stock/models/stock.py#L164 sentry-7089149997 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239030
This update resolves a technical issue that prevented users from running the automated download of vendor invoices from the Polish KSeF system when rate limits were exceeded. The fix ensures that error messages are handled correctly, preventing a common traceback error and allowing the scheduled action to continue functioning properly.
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 users creating freelance employees would receive an error message about missing SDWorx codes. The fix ensures that the system correctly skips this validation check for freelancers, streamlining the export process and preventing unnecessary errors.
Original PR description
Steps to reproduce: ------------------------------- 1. Install `l10n_be_hr_payroll_sd_worx` module 2. Switch the active company to a Belgian company 3. Go to Employees and create a new employee. Set the Employee Type to Freelancer from HR Settings page. 4. Navigate to Payroll > Reporting > Export Work Entries to SDWorx Observation: ------------------------------- A user error is raised stating: ``` There is no SDWorx code defined for the following employees ``` Issue: ------------------------------- The filter checking for missing SDWorx codes did not exclude employees with the Freelance employee type. SDWorx code does not passed to the freelancers Solution: ------------------------------- Add a condition to the employee filter to exclude freelance employees from the SDWorx code validation. opw-5387342 Forward-Port-Of: odoo/enterprise#102211
This update resolves an issue preventing new employee creation when generating BVG-LLP reports. The fix addresses a technical problem within Odoo's reporting system related to how it handles multiple report records with the same month, preventing a critical error. This ensures employees can be correctly created within the Swiss payroll process.
Original PR description
Steps to reproduce: ---------------------------------- 1. Install `l10n_ch_hr_payroll_elm_transmission` module 2. Switch to Swiss company 3. Navigate to Payroll > Transmission > BVG-LLP Basis…
Steps to reproduce:
----------------------------------
1. Install `l10n_ch_hr_payroll_elm_transmission` module
2. Switch to Swiss company
3. Navigate to Payroll > Transmission > BVG-LLP Basis Declaration
4. Create two Reports with same Year and Month
5. Now try to create new Employee from the employee app
Observation:
----------------------------------
Tracaback Occurs:
```
File '/home/odoo/src/enterprise/19.0/l10n_ch_hr_payroll/models/l10n_ch_employee_monthly_values.py', line 319, in _compute_bvg_lpp_annual_basis
existing_declaration = max(existing_declaration, key=lambda r: r.month) if existing_declaration else False
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File '/home/odoo/src/odoo/19.0/odoo/orm/models.py', line 5934, in ensure_one
raise ValueError('Expected singleton: %s' % self)
ValueError: Expected singleton: l10n.ch.lpp.basis.report(1, 2)
```
Issue:
----------------------------------
In the following code:
https://github.com/odoo/enterprise/blob/44a26539093f9313d9cd5f823c11866e3c98ec97/l10n_ch_hr_payroll_elm_transmission/models/l10n_ch_employee_monthly_values.py#L319-L320
Python's max() function doesn't just call the key function once per item. When there are ties (equal key values), it may need to compare the original objects, and during this process, Odoo's recordset operations combine records, causing the lambda receives `r` as a combined recordset. To access `.month` on a multi-record recordset it gives singleton error.
Solution:
----------------------------------
Creates tuples of (month, recordset) pairs and uses max() to compare month integers directly, avoiding the singleton error.
opw-5391742
Forward-Port-Of: odoo/enterprise#102335This update resolves an issue where the bulk payment feature would crash if a bank account wasn't linked. A new user message now alerts users to ensure their payment journal is connected to a bank before checking batch status, improving the user experience and preventing errors.
Original PR description
This commit: https://github.com/odoo/enterprise/commit/c9cc89f58f7d98396afac3bdacfeff9b00a02a21 introduce the initiate bulk payments feature. When selecting a batch you can also check the status of this batch. But for the moment, if you select a batch that is not connected to a bank, the action will traceback with a redirect. This commit will add a user error to warn the user than the journal needs to be connected to a bank. task-6009083 Forward-Port-Of: odoo/enterprise#110474 Forward-Port-Of: odoo/enterprise#109956
This update resolves a test failure caused by overly sensitive checks for loading indicators (fa-spin). The trigger has been removed, ensuring tests run smoothly even with minor delays in the system. This improves the reliability of our testing process.
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 system correctly handles file uploads, specifically by verifying the MIME type passed to the 'File' constructor. This change aligns with Chrome's latest standards and prevents compatibility issues with older browser versions, ensuring smoother file operations.
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 that new files created within the Odoo Enterprise system correctly identify their file types (mimetypes). This fix addresses a compatibility issue with older versions of Chrome, aligning with current web standards and preventing 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#110812 Forward-Port-Of: odoo/enterprise#110496
This update ensures that payments received from external providers are always fully reconciled – either completely paid or not paid at all. Previously, partial reconciliation was allowed, which created an inaccurate record of transactions. This change improves the accuracy of financial reporting.
Original PR description
When we receive a payment from a provider, we allow partial reconciliations to be done on this move, but we shouldn't. Payments coming from providers are always either fully paid, or not paid at all. task-5893189
A test was failing due to inconsistencies in the system's clock. This update ensures the test accurately measures the time it takes for a bill retry process, guaranteeing reliable test results and preventing potential delays in automated bill downloads. This improves the stability of the l10n_pl_edi module.
Original PR description
The test `TestL10nPlEdi.test_l10n_pl_edi_download_bill_retry_after` was failing with a stack like following, because the `now()` time was taken after the cron was executed, making the time diff sometimes shorter than the required 120s.
```
FAIL: TestL10nPlEdi.test_l10n_pl_edi_download_bill_retry_after
Traceback (most recent call last):
File "/data/build/odoo/addons/l10n_pl_edi/tests/test_l10n_pl_edi.py", line 619, in test_l10n_pl_edi_download_bill_retry_after
self.assertGreaterEqual(capt.records[-1].call_at, fields.Datetime.now() + timedelta(seconds=120))
~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: datetime.datetime(2026, 2, 21, 4, 20, 7) not greater than or equal to datetime.datetime(2026, 2, 21, 4, 20, 8)
```
runbot-241016
Forward-Port-Of: odoo/odoo#254234This update resolves an issue where changing the copyright footer background color would cause a CSS error when the footer had no background color. The fix adds a fallback value to ensure the copyright color displays correctly regardless of the footer's background setting, improving website appearance consistency.
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 fixes a display problem with the mega menu on mobile devices. Previously, when the mega menu was set to 'Narrow,' it would sometimes take up too much space. This change ensures the mega menu's width is correctly controlled, preventing oversized displays and maintaining a consistent user experience.
Original PR description
The property "max-width" of the mega menu in mobile view was set with the class o_mega_menu_is_offcanvas of its ancestor. However, when the user set the mega menu template size to "Narrow", new CSS rules were added to change the mega menu size based on the screen size. The first rule was overridden, resulting in the mega menu being larger than the mobile navbar width. This commit sets the property "max-width" as "important" to prevent this issue from occurring. task-5972284 Forward-Port-Of: odoo/odoo#250690
This update simplifies invoice processing by automatically enabling self-billing for all users within the Odoo system. Previously, this feature required a separate module. Additionally, the xRechung functionality has been removed, ensuring invoices are only sent to government entities as intended.
Original PR description
Everybody is now able to receive self billing invoices even without the additional module. So the service should be added to the base module. Also remove xRechung because users are not supposed to receive it, only government. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254341
This update resolves an issue where the delivery process would fail if Sendcloud, our shipping provider, didn't respond to a request for shipping prices. The fix prevents a system error (traceback) from occurring, ensuring smoother and more reliable delivery processing. This improvement enhances the overall reliability of our shipping functionality.
Original PR description
Sendcloud sometimes doesn't respod when asking for `shipping-price`. So when we try to retrieve the first element of the response, we raise an `IndexError`. ----- Ticket: opw-5951749 Forward-Port-Of: odoo/enterprise#109252
7 changes
Resolved issues and error corrections
This update resolves an issue where night shift slots (e.g., 20PM - 4AM) weren't visible in the weekly planning view. The fix adjusts how the system calculates display hours for multi-day shifts, ensuring all scheduled time is accurately represented. This improves the planning experience for employees with flexible work arrangements.
Original PR description
**Steps to reproduce** 1. Have an employee using a flexible schedule 2. Create a slot from e.g. 20PM to 4AM for this employee. Make sure this is the only slot that week for the employee. 3. Publish…
**Steps to reproduce** 1. Have an employee using a flexible schedule 2. Create a slot from e.g. 20PM to 4AM for this employee. Make sure this is the only slot that week for the employee. 3. Publish the Schedule and send it to the employee. Open the outgoing mail to access the link to the planning view. Issue: the slot is not visible in the week view. **Cause** https://github.com/odoo/enterprise/blob/04a885dbb6eed96297cb5ce9a155ebf8e169427c/planning/controllers/main.py#L193-L194 The `event_hour_min` and `event_hour_max` returned by `planning_get` and used to control the min/max hours displayed in the week view, didn't account for slots over multiple days. For a slot between 20pm and 4am, the `event_hour_max` should be the end of the day, and the `event_hour_min` should be the start of the day. **Solution** - we change the `event_hour_min` and `event_hour_max` for multi-day slots to display the full days in the week view - the previous point has the drawback of displaying the full days for non-flexible employees even when not necessary. This is because `slots_start_datetime` and `slots_end_datetime` contained the `planning.slot` start and end. Instead, we can look at the actual slot values displayed (by `_get_slots_vals`). For example, a 5 day slot for a non-flexible employee may contain actual slot values corresponding to a typical 8-17 working day. opw-5245985 Forward-Port-Of: odoo/enterprise#99784
This update fixes a bug where project timesheets didn't accurately reflect changes in employee costs when switching workers on a manufacturing order. The fix ensures that the AAL (analytic accounting line) associated with the work center is updated correctly, accurately tracking labor costs in the project dashboard. This ensures accurate project costing and reporting.
Original PR description
### Steps to reproduce: - Create an MTO product and another Service product that create a project and task - Create a quotation with both products - Create two employees with different hourly cost - Go to Manufacturing order - Configure an employee to manufacture the product at a work station. - Observe the project dashboard - Go back to the MO and change the employee on the work station - Notice the project dashboard Timesheets section doesn't have any change on the amount ### Cause: This is happening because when changing the employee we don't modify anything in the AAL linked to the work station. As we only modify the AAL when the duration change. ### Fix: We call _create_analytic_entry when we change the employee on the work station to change the amount and the employee_id for the AAL. opw-5939321 Forward-Port-Of: odoo/enterprise#109695
This update ensures that shift notifications 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 adjusts the demo certificate used in testing to ensure it remains valid for a longer period. The previous certificate expired in 2027, but this change extends its lifespan to 2036, resolving a potential issue with test timelines. This ensures continued accurate testing of the PE compliance features.
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 corrects a previous error that prevented freelancers from exporting payroll data to SDWorx. The change ensures that the system no longer flags missing SDWorx codes for freelancers, streamlining the export process and preventing user confusion. This resolves a technical issue impacting Belgian company users.
Original PR description
Steps to reproduce: ------------------------------- 1. Install `l10n_be_hr_payroll_sd_worx` module 2. Switch the active company to a Belgian company 3. Go to Employees and create a new employee. Set the Employee Type to Freelancer from HR Settings page. 4. Navigate to Payroll > Reporting > Export Work Entries to SDWorx Observation: ------------------------------- A user error is raised stating: ``` There is no SDWorx code defined for the following employees ``` Issue: ------------------------------- The filter checking for missing SDWorx codes did not exclude employees with the Freelance employee type. SDWorx code does not passed to the freelancers Solution: ------------------------------- Add a condition to the employee filter to exclude freelance employees from the SDWorx code validation. opw-5387342 Forward-Port-Of: odoo/enterprise#102211
This update resolves an issue preventing new employee creation when generating the BVG-LLP Basis Declaration report. The fix addresses a technical problem with how Odoo compares report records, ensuring the system correctly handles multiple reports with the same month.
Original PR description
Steps to reproduce: ---------------------------------- 1. Install `l10n_ch_hr_payroll_elm_transmission` module 2. Switch to Swiss company 3. Navigate to Payroll > Transmission > BVG-LLP Basis…
Steps to reproduce:
----------------------------------
1. Install `l10n_ch_hr_payroll_elm_transmission` module
2. Switch to Swiss company
3. Navigate to Payroll > Transmission > BVG-LLP Basis Declaration
4. Create two Reports with same Year and Month
5. Now try to create new Employee from the employee app
Observation:
----------------------------------
Tracaback Occurs:
```
File '/home/odoo/src/enterprise/19.0/l10n_ch_hr_payroll/models/l10n_ch_employee_monthly_values.py', line 319, in _compute_bvg_lpp_annual_basis
existing_declaration = max(existing_declaration, key=lambda r: r.month) if existing_declaration else False
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File '/home/odoo/src/odoo/19.0/odoo/orm/models.py', line 5934, in ensure_one
raise ValueError('Expected singleton: %s' % self)
ValueError: Expected singleton: l10n.ch.lpp.basis.report(1, 2)
```
Issue:
----------------------------------
In the following code:
https://github.com/odoo/enterprise/blob/44a26539093f9313d9cd5f823c11866e3c98ec97/l10n_ch_hr_payroll_elm_transmission/models/l10n_ch_employee_monthly_values.py#L319-L320
Python's max() function doesn't just call the key function once per item. When there are ties (equal key values), it may need to compare the original objects, and during this process, Odoo's recordset operations combine records, causing the lambda receives `r` as a combined recordset. To access `.month` on a multi-record recordset it gives singleton error.
Solution:
----------------------------------
Creates tuples of (month, recordset) pairs and uses max() to compare month integers directly, avoiding the singleton error.
opw-5391742
Forward-Port-Of: odoo/enterprise#102335This update resolves a test failure caused by an overly sensitive check for loading indicators (fa-spin). The trigger has been removed, ensuring that minor delays in the system don't incorrectly flag issues during testing. This improves the stability and reliability of the system.
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
2 changes
Resolved issues and error corrections
This update resolves an issue where users were receiving an error message when exporting payroll data to SDWorx for freelance employees. The fix ensures that the system correctly skips the SDWorx code validation step for freelancers, streamlining the export process and preventing unnecessary errors.
Original PR description
Steps to reproduce: ------------------------------- 1. Install `l10n_be_hr_payroll_sd_worx` module 2. Switch the active company to a Belgian company 3. Go to Employees and create a new employee. Set the Employee Type to Freelancer from HR Settings page. 4. Navigate to Payroll > Reporting > Export Work Entries to SDWorx Observation: ------------------------------- A user error is raised stating: ``` There is no SDWorx code defined for the following employees ``` Issue: ------------------------------- The filter checking for missing SDWorx codes did not exclude employees with the Freelance employee type. SDWorx code does not passed to the freelancers Solution: ------------------------------- Add a condition to the employee filter to exclude freelance employees from the SDWorx code validation. opw-5387342 Forward-Port-Of: odoo/enterprise#102211
This update corrects a problem where employee documents were being accessed using the wrong website domain, leading to incorrect URLs. The fix ensures documents are accessed using the correct, system-defined base URL, improving document access reliability.
Original PR description
Steps to reproduce: --------------------------------- 1. Install `documents_hr` and `website_documents` modules 2. Go to website > configuration > websites 3. In My Website set any arbitary domain…
Steps to reproduce: --------------------------------- 1. Install `documents_hr` and `website_documents` modules 2. Go to website > configuration > websites 3. In My Website set any arbitary domain (e.g. https://test.com) 4. Open any employee record 5. Click on Documents smart button Observation: --------------------------------- It will try to open employee's documents with the website's domain, e.g. `https://test.com/odoo/documents/xyz` Issue: --------------------------------- After the following commit: https://github.com/odoo/enterprise/pull/92774/changes/46c43c14fb2a0fb7b693ede53cc84dbf8bdc9bcb the smart button redirects to the document folder via an access token. The `access_url` is computed using `get_base_url()`, which is overridden by the website module to return the website domain instead of the system base URL. https://github.com/odoo/odoo/blob/f6cf0d067e5f30e2b22ea513071cd7c5e3d9f44c/addons/website/models/ir_model.py#L10-L36 Solution: --------------------------------- Added a context-based check to `get_base_url()`. When the context key `use_config_parameter_domain` is set, and the record has a `website_id` field, the system base URL from the configuration parameters is used instead of the website domain. This allows any model to explicitly rely on the configured base URL when required NOTE: No module installs `hr`, `documents` and `website`, so test case is not possible without bridge module of all three Related Community PR: https://github.com/odoo/odoo/pull/247920 opw-5471683
10 changes
Enhancements to existing features
This update enhances our testing process by allowing developers to easily specify the Chrome/Chromium browser version used during tests. This simplifies debugging issues related to browser-specific problems and ensures consistent testing across different browser versions. It's a small change that improves our ability to quickly identify and resolve browser-related bugs.
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
Resolved issues and error corrections
This update resolves an issue where the bank statement import process would fail when the currency in a CAMT file didn't match the bank's journal currency. The fix now validates for missing currency data, preventing errors and ensuring accurate bank statement imports. This improves the reliability of the import process.
Original PR description
Currently, an error occurs when the currency in the CAMT file differs from the bank journal currency. **Steps to reproduce:** - Install `account_bank_statement_import` module. - Create a new country…
Currently, an error occurs when the currency in the CAMT file differs from the bank journal currency. **Steps to reproduce:** - Install `account_bank_statement_import` module. - Create a new country with EUR as currency and switch to it. - In the Bank journal, upload this CAMT file: https://drive.google.com/file/d/1hKZIUPwdtcWAvxcoTLPFGpW-F5LnqDy9/view?usp=drive_link **Error:** `TypeError - unsupported operand type(s) for /: 'NoneType' and 'float'` **Cause:** When the `<Bal>` or `<Ntry>` amounts in the CAMT file are in a different currency, `get_value_and_currency_name` [1] cannot fetch a matching amount for the journal currency. This returns `None`, which leads to an invalid division during exchange rate computation. **Fix:** This commit handles missing currency data in CAMT files by raising a validation error instead of throwing a traceback. [1] - https://github.com/odoo/enterprise/blob/e7ae981000a4e53dc608c76605d8b2dbfb972c6a/account_bank_statement_import_camt/lib/camt.py#L632-L638 sentry-6874016845
This update corrects an issue where the QR code generated for self-ordering pickup orders incorrectly included table information in the downloaded PDF. The fix ensures QR codes are generated without table IDs, resolving a problem that prevented proper order scanning at the pickup zone. This improves the reliability of the self-ordering process.
Original PR description
Step to reproduce: - setup Restaurant and do the following config - set "self-ordering" -> "Qr Menu + Ordering" - set "service At" -> "pickup zone" - save and print the qr-code ( option is right there below these configs) Observation: - in downloaded pdf, we see a wrong url, which includes table_id, which shouldn't be. - QRs do not have table_id Cause: - there is issue in `generate_qr_codes_page` method, which uses table_id even if ordering mode is "pickup zone" Fix: - we only use table_id when ordering_mode = 'table'. **Before:** <img width="1002" height="397" alt="image" src="https://github.com/user-attachments/assets/e6dc50e5-6384-45b8-8ee5-817526769dc2" /> **After** <img width="1021" height="405" alt="image" src="https://github.com/user-attachments/assets/0be9b902-3870-4fc7-a409-e01265b7a1b3" /> opw-5095607 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247184
This update corrects a previous error that prevented freelancers from exporting payroll data to SDWorx. The change ensures that the system no longer flags missing SDWorx codes for freelancers, streamlining the export process. This resolves a user-reported issue impacting Belgian companies using the SDWorx integration.
Original PR description
Steps to reproduce: ------------------------------- 1. Install `l10n_be_hr_payroll_sd_worx` module 2. Switch the active company to a Belgian company 3. Go to Employees and create a new employee. Set the Employee Type to Freelancer from HR Settings page. 4. Navigate to Payroll > Reporting > Export Work Entries to SDWorx Observation: ------------------------------- A user error is raised stating: ``` There is no SDWorx code defined for the following employees ``` Issue: ------------------------------- The filter checking for missing SDWorx codes did not exclude employees with the Freelance employee type. SDWorx code does not passed to the freelancers Solution: ------------------------------- Add a condition to the employee filter to exclude freelance employees from the SDWorx code validation. opw-5387342 Forward-Port-Of: odoo/enterprise#102211
This update resolves an issue preventing new employee creation when generating the BVG-LLP Basis Declaration report. The fix addresses a technical problem related to how Odoo processes multiple reports with the same month, ensuring correct employee data is recorded. This improves the reliability of payroll reporting for Swiss companies.
Original PR description
Steps to reproduce: ---------------------------------- 1. Install `l10n_ch_hr_payroll_elm_transmission` module 2. Switch to Swiss company 3. Navigate to Payroll > Transmission > BVG-LLP Basis…
Steps to reproduce:
----------------------------------
1. Install `l10n_ch_hr_payroll_elm_transmission` module
2. Switch to Swiss company
3. Navigate to Payroll > Transmission > BVG-LLP Basis Declaration
4. Create two Reports with same Year and Month
5. Now try to create new Employee from the employee app
Observation:
----------------------------------
Tracaback Occurs:
```
File '/home/odoo/src/enterprise/19.0/l10n_ch_hr_payroll/models/l10n_ch_employee_monthly_values.py', line 319, in _compute_bvg_lpp_annual_basis
existing_declaration = max(existing_declaration, key=lambda r: r.month) if existing_declaration else False
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File '/home/odoo/src/odoo/19.0/odoo/orm/models.py', line 5934, in ensure_one
raise ValueError('Expected singleton: %s' % self)
ValueError: Expected singleton: l10n.ch.lpp.basis.report(1, 2)
```
Issue:
----------------------------------
In the following code:
https://github.com/odoo/enterprise/blob/44a26539093f9313d9cd5f823c11866e3c98ec97/l10n_ch_hr_payroll_elm_transmission/models/l10n_ch_employee_monthly_values.py#L319-L320
Python's max() function doesn't just call the key function once per item. When there are ties (equal key values), it may need to compare the original objects, and during this process, Odoo's recordset operations combine records, causing the lambda receives `r` as a combined recordset. To access `.month` on a multi-record recordset it gives singleton error.
Solution:
----------------------------------
Creates tuples of (month, recordset) pairs and uses max() to compare month integers directly, avoiding the singleton error.
opw-5391742
Forward-Port-Of: odoo/enterprise#102335This update resolves a problem where header border widths were incorrectly set to full widths due to a design flaw in the input field. The change ensures consistent border behavior for standard headers while still allowing full borders for specific header templates. This improves the visual consistency of Odoo websites.
Original PR description
Previously, the border width input for headers allowed multiple values. This was required for specific header templates (e.g. rounded box) that use a full border. However, most headers only apply a border on the bottom. When the input had multiple values, the scss would break, resulting in full border. This change ensures that, for headers without the .o_full_border class, only the first value of the saved border width is used. As a result, the input behaves like a single-value field (similar to font size inputs) for standard headers, while still supporting multiple values for templates that require a full border. Steps to reproduce the issue: - Go to Edit mode - Click on the Header - In the Border option, enter "1 2" and leave the input to validate => The input display "3" and the header has a full border. task-5500516 Forward-Port-Of: odoo/odoo#244415
This update corrects a bug in the Odoo portal's task search functionality. Previously, searching by assignees didn't return accurate results due to a naming error in the search criteria. This fix ensures that tasks assigned to a specific user are correctly displayed when searching by assignee, improving user task visibility.
Original PR description
# How to reproduce - On the website go to My Account > Tasks - In the search bar, select Search In Assignees - Search for an assignee # The problem Nothing shows up even if the is a task with the assignee that was searched # Why In the dictionnary of the different possible searches, the name of the Search in Assignee entry was "users" instead of "user_ids" opw-5503738 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update improves how charges are handled on invoices generated using UBL/BIS3. Previously, charges created separate invoice lines. Now, the charge amount is directly added to the original invoice line's price unit, streamlining invoice creation and ensuring accurate financial reporting. This change simplifies the process for users and improves data consistency.
Original PR description
Before this commit: A charge in an InvoiceLine was creating a new invoice line with the amount of the charge. After this commit: The charge is added in the price unit of the original line --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where the copyright background color wouldn't display correctly on the website footer if the footer itself had no background color. The change adds a fallback value to the CSS, ensuring the copyright color is always visible regardless of the footer's background setting. This improves the website's appearance and consistency.
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 corrects a problem where Amazon listings were incorrectly syncing stock levels, leading to phantom orders. The fix allows users to manually specify the fulfillment channel (FBA or FBM) for each listing, resolving a known 'ghost listing' issue. This ensures accurate stock management and order fulfillment on Amazon.
Original PR description
When configuring a listing on Amazon Seller Central, the user must choose **one** of the available fulfillment channels that Amazon offers. We distinguish two kinds: Fulfillment by Amazon (FBA) and…
When configuring a listing on Amazon Seller Central, the user must choose **one** of the available fulfillment channels that Amazon offers. We distinguish two kinds: Fulfillment by Amazon (FBA) and Fulfillment by Merchant (FBM). However, Amazon suffers from a known issue of ghost listings. A ghost listing occurs when an offer is presumably sold via FBA, but in fact stores stock information for both FBM and FBA creating unwanted FBM orders. To avoid ghost listings, the first solution was to disable stock synchronization as soon as an offer contained stock in the Amazon location of Odoo. However, if a merchant decided to change the fulfillment channel, it became impossible to sync the stock anymore. See also e7c01c7097d90e731c5408cee4d3595ed810c8fa. To resolve this issue, we decided to use the Amazon API to fetch information about the fulfillment channel of a listing. However, Amazon doesn't give a clear answer for a given listing. Therefore, after some research, the assumption was that an offer was FBM if the listing contained a `merchant_shipping_group`, as the merchant shipping group is a setting specific to FBM listings. See also e6d620e4b200cadabb00ce37ab03289cfeb4ae58. However, this assumption was flawed because Amazon can keep the shipping group even if the listing switches to FBA. This in turn enabled stock synchronization, leading to ghost listings. To fix this issue we give the possibility to users to manually set the correct fulfillment channel of an offer when it becomes ambiguous. opw-5480254 See also: - https://github.com/odoo/upgrade/pull/9692 Forward-Port-Of: odoo/enterprise#106662
1 change
Resolved issues and error corrections
This update resolves a visual issue where the map view in the 'My Dashboard' sometimes collapsed. The fix removes conflicting height settings and adds a minimum height to the map, ensuring it always displays correctly regardless of the number of records shown.
Original PR description
This commit fixes rendering height issues when the map view is displayed inside "My Dashboard". * Removed `height: 100%` from the map and pin list containers. This conflicting rule interfered with the flexbox layout, often causing the map to collapse entirely since it couldn't compute its own height. * Added a `min-height` to the map renderer. This ensures the map always occupies a reasonable amount of space in the dashboard, even when there are few or no records to display. task-6022958 Forward-Port-Of: odoo/enterprise#110790