Daily updates from Odoo
Monday, July 13, 2026
303 changes
19 changes
New functionality added to Odoo
This update provides Russian translations for the Chart of Accounts data within the Odoo localization module for Uzbekistan. Recognizing the widespread use of Russian in Uzbek accounting, this change expands Odoo's usability and adoption among local users. This supports a key market and improves the overall user experience.
Original PR description
This change adds Russian translations for the Chart of Accounts data in the l10n_uz module. Standard practice is to enable only a country's official statutory language in localization modules However, the business reality of Central Asia particularly Uzbekistan justifies an exception: Russian is widely used in accounting practice there, and supporting it will significantly improve adoption among local users. task-6229114 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#274137 Forward-Port-Of: odoo/odoo#269320
Enhancements to existing features
Odoo can now use official daily exchange rates from the Central Bank of Azerbaijan for automatic currency updates. This helps businesses using AZN translate foreign-currency accounting and tax transactions more accurately, including rates quoted for larger nominal amounts.
Original PR description
This commit adds the Central Bank of Azerbaijan (CBA) as a supported service provider for automatic currency rate updates. Purpose: To ensure multi-currency accounting entries and taxable transactions are accurately translated into the national currency (AZN) using the official exchange rate defined by the CBA for the transaction day. Functionality: -Enables fetching official daily exchange rates directly from CBA via XML. -Automatically handles rates defined for different nominal quantities (e.g., rates quoted per 100 units instead of 1 unit). Backport of: https://github.com/odoo/enterprise/pull/122626 task-6112867 Forward-Port-Of: odoo/enterprise#123436
Work order planning views now focus on planned work by default, reducing the chance of accidental replanning and keeping completed manufacturing dependencies out of planning charts. Shop floor card options now better match enabled settings, and engineering change cost comparisons are more accurate for operation changes.
The AI app now marks an upcoming retired Google embedding model as deprecated and automatically refreshes older embeddings that used deprecated models. This helps keep AI-powered features reliable without manual intervention when providers phase out older models.
Original PR description
The model gemini-embedding-001 will be deprecated soon, so this commit is: - Deprecating that model. - Introducing an autovacuum to recompute embeddings that were done using embedding models that have been deprecated. task-6004597
Resolved issues and error corrections
Employees and payroll teams can now access the payslip correction option directly from a payslip. This restores expected payroll workflow behavior and helps users correct payslip issues without needing to navigate elsewhere.
Original PR description
The payslip correction should also be available on the payslip. This is a backport of commit 117f0117a839cd29cb9f52aaf52b1e25efe1e314 task-6374294 Forward-Port-Of: odoo/enterprise#123558
The payroll pay run warning for missing payslips now works correctly again. This helps payroll teams catch incomplete pay runs before processing, reducing the risk of missed employee payments.
Original PR description
The missing payslip in a payrun warning wasn't triggered correctly because we were filtering on the schedule pay of the payrun and this field was removed in a previous PR. task-6329134 Forward-Port-Of: odoo/enterprise#121641
Fixed an issue where subscription product pages could fail when a discount was set directly on a recurring plan without a pricelist. Customers can now view the product page and see the correct discounted recurring price instead of an error.
Original PR description
**Problem:** On the website, a subscription product page returns a 500 error when a discount is set directly on the recurring plan (a time-based pricing rule with a plan but no pricelist). **Steps to…
**Problem:** On the website, a subscription product page returns a 500 error when a discount is set directly on the recurring plan (a time-based pricing rule with a plan but no pricelist). **Steps to reproduce:** 1. Create a subscription product with a recurring plan. 2. Add a recurring price rule for that plan with no pricelist, set as a percentage discount (base = sales price). 3. Open the product page on the website. **Current behavior:** The page fails with a 500: Internal Server Error during price computation. **Expected behavior:** The page loads and shows the discounted recurring price. **Cause of the issue:** For a recurring price rule based on the sales price, `_compute_base_price` looks up "the no-pricelist rule for the plan" to use as its base, via `_get_applicable_rules_domain(plan_id=...)`. When the discount is set directly on the plan, the rule being computed has no pricelist itself, so that search returns the very same rule and calls `_compute_price` on it again, leading to infinite recursion. **Fix:** Excluding the rule itself from the base-rule lookup lets a no-pricelist plan rule resolve its base from the product's sales price (the super() fallback) instead of re-entering its own computation. A rule applied through a pricelist is unaffected, since its no-pricelist base rule is a different record. opw-6306105 Forward-Port-Of: odoo/enterprise#121466
Draft planning entries in My Planning now display with the expected hatched styling instead of looking like confirmed entries. This makes it easier for users to distinguish draft plans at a glance and avoid confusion when reviewing schedules.
Original PR description
Issue: Calendar entries appear plain even when they should appear hatched. (ex. while in draft status) Steps to reproduce: If you create any planning and set it to draft. Then go to Planning > Planning > My Planning, the newly created plan should be in hatched but it becomes plain. Cause: In the view planning.slot.my.calendar there was missing the element that causes the views to become hatched when in draft status. Solution: Added said element. opw-6260055 Forward-Port-Of: odoo/enterprise#119153
Cloud attachments downloaded through signed URLs were saved with generic blob names because the link did not carry the original mimetype. Embed Content-Disposition and Content-Type in Azure and Google download URLs, and set Content-Type when uploading. GCS signed URL v4 validation requires alphabetically sorted query parameters once response headers are added to the signature. task-6359564 https://github.com/odoo/documentation/pull/18771 Description of the issue/feature this PR a
Original PR description
Cloud attachments downloaded through signed URLs were saved with generic blob names because the link did not carry the original mimetype. Embed Content-Disposition and Content-Type in Azure and Google download URLs, and set Content-Type when uploading. GCS signed URL v4 validation requires alphabetically sorted query parameters once response headers are added to the signature. task-6359564 https://github.com/odoo/documentation/pull/18771 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#275791 Forward-Port-Of: odoo/odoo#274019
This update fixes a situation where the 'Invoice' button was incorrectly displayed in the repair module. Now, the button will only appear after a repair has been successfully completed, ensuring users only see relevant options. This change is part of the v19.4 release and will be cleaned up in subsequent versions.
Original PR description
This button should appear only when a repair is done. Note: the existing mechanism wil be cleaned post v19.4 release task: 6379961 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a bug where the Peppol demo mode wasn't correctly applied to databases that had previously been neutralized. Previously, the system defaulted to production mode, leading to incorrect document registration. This fix ensures the demo mode is properly set when installing Peppol on a neutralized database, preventing unintended data transmission to the live Peppol network.
Original PR description
When Peppol is installed on a database that was already neutralized (ex: a staging database where the feature is enabled after the neutralization happened), the account_peppol.edi.mode parameter is not set: data/neutralize.sql only runs at neutralization time, not when the module is installed afterwards. The demo/ data that also sets this parameter is not loaded on databases without demo data (real production/staging databases). As a result, _get_peppol_edi_mode() falls back to 'prod' and the neutralized database registers and sends documents against the live Peppol network. Steps to reproduce: - Neutralize a database on which Peppol is not installed yet - Install the account_peppol module - Open the Peppol settings / registration wizard: the mode is Production instead of Demo Force the demo mode in the pre_init_hook when the database is neutralized, mirroring data/neutralize.sql opw-6307710 Forward-Port-Of: odoo/odoo#275210 Forward-Port-Of: odoo/odoo#273019
This update resolves a minor issue where pressing the Tab key within a link preview in Odoo would cause a technical error. The fix ensures smooth navigation within link previews, improving the user experience. This change was part of a larger effort to maintain stability and usability.
Original PR description
Since [1] elements within the link preview can be focused. However, when pressing tab an error is raised. This commit prevents this error from happening. [1]: https://github.com/odoo/odoo/commit/34db19f4a2b42d7e41205d7d793f5b3f408c19af task-6366337 Forward-Port-Of: odoo/odoo#275638 Forward-Port-Of: odoo/odoo#274682
This update resolves an issue where attachments were incorrectly flagged as 'unsupported' when using non-UBL sending methods. The fix also corrects a minor typo, ensuring accurate attachment handling for invoices sent via UBL and other methods. This improves the reliability of invoice delivery.
Original PR description
In the send wizard, don't mark attachments as "unsupported" if the sending method is not ubl dependent Also fix a typo in "Unspported" no-task Forward-Port-Of: odoo/odoo#275301
This update streamlines the process of verifying EU VAT numbers when creating new companies. Previously, a redundant verification step was performed twice, impacting performance. This change consolidates the verification to a single call, optimizing the system and reducing potential delays.
Original PR description
When we create a company with a EU VAT, we used to do 2 IAP call to verify the VAT number. One was on the create() and the other one on the write(). For performance reason and because the vies check service may limit ip address, the verification was already disable when importing files (in both create and write). This commit remove the compute on the create one (and keep the one on write), so that it only do 1 IAP call to verify the VAT. Task-6139346 Forward-Port-Of: odoo/odoo#275456 Forward-Port-Of: odoo/odoo#274644
This update fixes an issue where employees were incorrectly showing as having no remaining holiday days after being allocated time off. The fix ensures that the system accurately reflects available leave balances by correctly passing the target date through the calculation process, even when using sudo contexts.
Original PR description
Bug : - Create a new employee (also works with old employees) - Create an allocation of Paid Time Off that is available in the future. - Create a Time Off request for this employee in the future. -…
Bug : - Create a new employee (also works with old employees) - Create an allocation of Paid Time Off that is available in the future. - Create a Time Off request for this employee in the future. - When Selecting Time off type you'll see that he has (0 remaining out of 0 days) even though he has just be allocated leaves. Reason : clicking on the many2one field => triggers web_name_search (line 53 in web/models/modeld.py) => triggers name_search (line 1514 in orm/models.py) , here we fetch the searched records with sudo , and when switching to sudo we call a function called clean_context this function (line 952 in odoo/tools/misc.py) remove elements from the context that start with the prefix default_ , in our case , we when clicking on the field we pass the target date through default_date_from , thus we lose it , and instead we make the calculations as if the target date was today Fix : pass the date_from through 'leave_date_from' given that _ compute_leaves already checks this context entry, this way we make sure to keep our start_date in the context even if we switch to sudo during some point in the calculation. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#273670
This update corrects a visual inconsistency in the website's accordion controls. A previous change unintentionally created duplicate styling rules, leading to different colors when the accordion was open or closed. This fix ensures a consistent and professional look across all accordion elements.
Original PR description
In commit[1] we restyled the accordion snippets, removing the background-image to use oi-icons instead. However due to selector specificty, the rule was taking priority. This :not is actually wrong since we want the color to apply as well when the accordion is collapsed (else you have 2 different colors between the collapsed uncollapsed state) task-6361379 [1]: f26a1535b96c728e4360d94c0c06de138a6b1b3f --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#274577 Forward-Port-Of: odoo/odoo#274016
This update fixes an issue where the cursor position in the Odoo Code Editor would jump unexpectedly while typing. By internalizing the cursor tracking, the editor now accurately reflects the user's typing, providing a smoother and more reliable editing experience. This improves usability for developers working within Odoo.
Original PR description
Steps to reproduce the issue: -> Open studio -> Edit any view -> Edit xml => Cursor moves backwards when typing Some components inside of the report editor were managing the cursor position based on the document manually. Rendering timings could cause the cursor to move while typing. This commit internalizes the cursor position in the CodeEditor and keep track of them based on the sessionsId, making sure that the cursor position is always correct and only changing when switching between sessions while also making the component API simpler. Enterprise: https://github.com/odoo/enterprise/pull/123244
Features or functions removed from Odoo
The Belgian payroll rules now stop applying the elderly worker reduction in Brussels starting in the third quarter of 2026. This keeps payroll calculations aligned with the updated regional rules and updates related checks accordingly.
Original PR description
removed the reduction for everyone in BXL starting Q3 2026 and adapted the tests task - 6331080
This update removes the 'Pay on Invoice' payment provider option from invoices. This change simplifies the payment process and aligns with best practices, as offering 'Pay on Invoice' for standard invoices was deemed unnecessary. It’s a minor adjustment to improve clarity and usability.
Original PR description
Paying an invoice with the pay-later provider "Pay on Invoice" doesn't make sense. Removing it from the list of available providers in such documents.
9 changes
Resolved issues and error corrections
This update resolves a problem preventing users from successfully downloading files through the FileViewer feature in Odoo. The previous issue stemmed from an incorrect port configuration, which has now been corrected. This ensures reliable file downloads for all users.
Original PR description
fix bad forward port 9a7ebe96750 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where the 'Load Demo Data' button in the Employee app would overflow text when the app was set to French or Arabic. The fix automatically adjusts the button's width to fit the text, ensuring a cleaner and more user-friendly experience. This improves readability and usability for all users.
Original PR description
Steps to reproduce: ---------------------------------------- - Be in a company with no employees - Switch to French or Arabic - Open the Employee app - The text in the button overflows Cause: ---------------------------------------- The button has a specified width: `w-100` And the text is `text-nowrap` So it overflows from the button box Solution: ---------------------------------------- Make the width auto adapt to the text with `w-auto`. Before: <img width="727" height="201" alt="image" src="https://github.com/user-attachments/assets/0347125b-1595-44ea-a0bd-b7c77e6c753d" /> After: <img width="723" height="236" alt="image" src="https://github.com/user-attachments/assets/18e40b39-f7b9-488c-9e47-3b9b82bdb445" /> opw-6345094 Forward-Port-Of: odoo/odoo#274405
This update resolves an issue where attachments were incorrectly flagged as 'unsupported' when using non-UBL sending methods. The fix also corrects a minor typo, ensuring accurate attachment identification. This improves the reliability of UBL invoice sending.
Original PR description
In the send wizard, don't mark attachments as "unsupported" if the sending method is not ubl dependent Also fix a typo in "Unspported" no-task Forward-Port-Of: odoo/odoo#275301
This update streamlines the verification of EU VAT numbers during company creation. Previously, a redundant check was performed twice, impacting performance. This change consolidates the verification process to a single call, optimizing efficiency and reducing potential issues with external service limitations.
Original PR description
When we create a company with a EU VAT, we used to do 2 IAP call to verify the VAT number. One was on the create() and the other one on the write(). For performance reason and because the vies check service may limit ip address, the verification was already disable when importing files (in both create and write). This commit remove the compute on the create one (and keep the one on write), so that it only do 1 IAP call to verify the VAT. Task-6139346 Forward-Port-Of: odoo/odoo#275456 Forward-Port-Of: odoo/odoo#274644
This update fixes several issues within the HTML editor's file box functionality, specifically within the Todo module. It now correctly handles plain text pasting, prevents unexpected cursor movement, and eliminates a scrollbar that appeared when the file box was empty. These changes ensure a smoother and more reliable editing experience.
Original PR description
### Purpose of this PR: * Prevent the powerbox from opening inside a static file box. * Paste content as plain text inside a static file box, since formatting is not supported there. * Prevent the cursor from leaving an empty file name box when pressing `ArrowLeft` or `ArrowRight`. * o_we_preview_favicon had a fixed height larger than its content, causing the link popover to overflow and show an unwanted scrollbar when the file input was empty as there was nothing to preview. Reduced the height to match the actual content size. * Shorthands (such as `#` for headings or `*` for lists) should not trigger when editing inside a file box. task-6283420 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#275308 Forward-Port-Of: odoo/odoo#268827
This update fixes an issue where employees were incorrectly showing as having no remaining holiday days after a new allocation. The fix ensures the system accurately reflects available leave time by correctly passing the allocation date through the calculation process, even when using sudo contexts.
Original PR description
Bug : - Create a new employee (also works with old employees) - Create an allocation of Paid Time Off that is available in the future. - Create a Time Off request for this employee in the future. -…
Bug : - Create a new employee (also works with old employees) - Create an allocation of Paid Time Off that is available in the future. - Create a Time Off request for this employee in the future. - When Selecting Time off type you'll see that he has (0 remaining out of 0 days) even though he has just be allocated leaves. Reason : clicking on the many2one field => triggers web_name_search (line 53 in web/models/modeld.py) => triggers name_search (line 1514 in orm/models.py) , here we fetch the searched records with sudo , and when switching to sudo we call a function called clean_context this function (line 952 in odoo/tools/misc.py) remove elements from the context that start with the prefix default_ , in our case , we when clicking on the field we pass the target date through default_date_from , thus we lose it , and instead we make the calculations as if the target date was today Fix : pass the date_from through 'leave_date_from' given that _ compute_leaves already checks this context entry, this way we make sure to keep our start_date in the context even if we switch to sudo during some point in the calculation. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#273670
This update corrects a bug where clickable carousel slides linked to 'odoo.com' would incorrectly redirect users to a website URL followed by 'odoo.com'. The fix ensures that carousel links function as intended, directing users to the correct Odoo domain. This resolves a potential usability issue for website visitors.
Original PR description
Steps to reproduce: - Drop any carousel - Set any slide to clickable - Set the link to "odoo.com" (without https://) - Save => On click, you are redirected to "yourwebsite.url/odoo.com" task-5949973
This update corrects a visual inconsistency in the website's accordion controls. A previous change caused the accordion to display two different colors depending on whether it was open or closed. This fix ensures a consistent color scheme across all accordion states, improving the overall user experience.
Original PR description
In commit[1] we restyled the accordion snippets, removing the background-image to use oi-icons instead. However due to selector specificty, the rule was taking priority. This :not is actually wrong since we want the color to apply as well when the accordion is collapsed (else you have 2 different colors between the collapsed uncollapsed state) task-6361379 [1]: f26a1535b96c728e4360d94c0c06de138a6b1b3f --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#274577 Forward-Port-Of: odoo/odoo#274016
This update fixes an issue where the quantity delivered in the Sales Order was incorrectly reduced after a refund was processed in the POS. The fix ensures accurate tracking of order quantities, even when refunds are issued, preventing discrepancies in order reporting. A new test has been added to proactively prevent this issue from recurring.
Original PR description
**Note: issue is not reproducible anymore, but still, we add the test to ensure, bug does not reappear in future** Step to reproduce: - create a SO with a order line - settle it in pos, notice in SO line, qty_delivered is 1 - refund the pos order - notice, in SO qty_delivered is -1 , not 0 Cause: - After commit [1] , `pos_order_line_ids` now includes order and refund lines - while the `_prepare_qty_delivered` relied on fact that refund lines are not part of `pos_order_line_ids` - due to this, quantity was reduced twice (refund amount are considered twice) [1] https://github.com/odoo/odoo/commit/a12db424a6986a58d1a328fd311078994ac17aee Fix: - in the compute, we now seperate refund and order lines and thus compute works perfectly opw-6290161 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#269996
13 changes
Resolved issues and error corrections
This update fixes several issues within the HTML editor's file box functionality, specifically within the Todo module. It now correctly handles plain text pasting, prevents unexpected cursor movement, and eliminates a scrollbar that appeared when the file box was empty. These changes ensure a smoother and more reliable editing experience.
Original PR description
### Purpose of this PR: * Prevent the powerbox from opening inside a static file box. * Paste content as plain text inside a static file box, since formatting is not supported there. * Prevent the cursor from leaving an empty file name box when pressing `ArrowLeft` or `ArrowRight`. * o_we_preview_favicon had a fixed height larger than its content, causing the link popover to overflow and show an unwanted scrollbar when the file input was empty as there was nothing to preview. Reduced the height to match the actual content size. * Shorthands (such as `#` for headings or `*` for lists) should not trigger when editing inside a file box. task-6283420 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#275308 Forward-Port-Of: odoo/odoo#268827
This update fixes an issue where duplicated printers lost their configured IP addresses, causing printing problems. The fix ensures that when a printer is duplicated, it retains the original IP address, simplifying setup and improving the Point of Sale functionality. This prevents disruptions to sales operations.
Original PR description
Steps to reproduce: ==== - Configure a printer from printers menu. - Duplicate the printer. Issue: ==== - The duplicated printer's IP address is reset to `0.0.0.0`. Cause: ==== - copy_data()` unconditionally overrides `printer_ip` with `0.0.0.0`. Fix: ==== - Stop overriding `printer_ip` so the duplicated printer inherits the original IP address by default. task-6365809
This update corrects a bug where an attendance record was incorrectly created when an employee took time off. The fix ensures that attendances are only generated when absences are justified, preventing misleading log notes and inaccurate attendance data. This change was introduced in a previous version and is now resolved.
Original PR description
# How to reproduce - In the settings, enable Absence Mangement - Create an employee with a Contract - Create a Time off for that employee for yesterday - Manually run the scheduled action…
# How to reproduce - In the settings, enable Absence Mangement - Create an employee with a Contract - Create a Time off for that employee for yesterday - Manually run the scheduled action "Attendance: Detect Absences for employees" - Go to the attendance dashboard for that employee # The issue An attendance with no overtime was created for yesterday for that employee with a log note saying "This attendance was automatically created to cover an unjustified absence on that day." However, the absence was justified as the employee took a time off. # Cause of the issue When running the `_cron_absence_detection` cron job, we create "empty" attendances for the employees that were absent yesterday. If those attendance's `overtime_hours` are 0, then we unlink them : https://github.com/odoo/odoo/blob/a73428187112b3948a11810abae2a3c82c9c7bcd/addons/hr_attendance/models/hr_attendance.py#L659-L666 But, since `check_in` and `check_out` cannot be the same, we cannot really create an empty attedance. We instead create an attendance of 1 second : https://github.com/odoo/odoo/blob/a73428187112b3948a11810abae2a3c82c9c7bcd/addons/hr_attendance/models/hr_attendance.py#L652-L653 This will create an overtime of 0.003 seconds if there was a leave that day (which is our case). This duration will be reflected in the attendance's `overtime_hours`. The issue is that we simply do `== 0` when trying to find the attendances without overtime, so we don't unlink them. The issue was introduced by : https://github.com/odoo/odoo/commit/8d7859a569d9ac7303ca0b9be6c56496be14c544 Because `round(0.003, 3)` => 0 but `round(0.003, 4)` => 0.003 The issue is not present in 18.0+ because we don't create overtime if the duration is `float_is_zero(overtime_duration, 2)` : https://github.com/odoo/odoo/blob/39cce855aa27aa4af9225a61a3e1425383a9f49f/addons/hr_attendance/models/hr_attendance.py#L405 opw-6321883 Forward-Port-Of: odoo/odoo#274865 Forward-Port-Of: odoo/odoo#272089
This update prevents unnecessary work entry regeneration when employees with validated entries are modified. Previously, an empty employee list triggered a slow, global regeneration process, impacting database performance. Now, the system stops regeneration when no valid employees remain, ensuring faster and more efficient work entry updates.
Original PR description
**Steps to Reproduce:** - Create an employee with at least one validated work entry. - Modify the employee's resource_calendar_id. - The schedule change triggers work entry recomputation. - During…
**Steps to Reproduce:** - Create an employee with at least one validated work entry. - Modify the employee's resource_calendar_id. - The schedule change triggers work entry recomputation. - During regeneration, the employee is excluded because of the validated work entry. - No valid employees remain for regeneration. **Issue:** - Employees with validated work entries are excluded from: `valid_employees = self.employee_ids - self.validated_work_entry_employee_ids` - When all employees are excluded, `valid_employees` becomes empty. - The flow still calls: `valid_employees.generate_work_entries(date_from, date_to, True)` - An empty employee recordset causes `generate_work_entries()` to follow the global generation path and fetch all employee versions in the requested period. `_get_all_versions_with_contract_overlap_with_period(date_start, date_stop)` - This can trigger unintended global work entry regeneration and cause severe performance issues on large databases. **Root Cause:** - The regeneration flow does not stop when no valid employees remain after excluding employees having validated work entries. - As a result, generate_work_entries() is called with an empty employee recordset, which falls back to the global generation path. **Solution:** - Stop the regeneration flow when the valid employee recordset is empty Because the employee already has a valid work entry, there is no need to regenerate. **Result:** - Prevents unintended generation on all employee versions. - Avoids unnecessary performance degradation on large databases. **OPW-6290122** 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#274787 Forward-Port-Of: odoo/odoo#270728
This update fixes an issue where the 'Load Demo Data' button in the Employee app would overflow text when the app was set to French or Arabic. The fix automatically adjusts the button's width to fit the text, ensuring a cleaner and more user-friendly experience. This improves readability and usability for all users.
Original PR description
Steps to reproduce: ---------------------------------------- - Be in a company with no employees - Switch to French or Arabic - Open the Employee app - The text in the button overflows Cause: ---------------------------------------- The button has a specified width: `w-100` And the text is `text-nowrap` So it overflows from the button box Solution: ---------------------------------------- Make the width auto adapt to the text with `w-auto`. Before: <img width="727" height="201" alt="image" src="https://github.com/user-attachments/assets/0347125b-1595-44ea-a0bd-b7c77e6c753d" /> After: <img width="723" height="236" alt="image" src="https://github.com/user-attachments/assets/18e40b39-f7b9-488c-9e47-3b9b82bdb445" /> opw-6345094 Forward-Port-Of: odoo/odoo#274405
This update fixes an issue where flexible employee overtime calculations were inaccurate due to timezone handling of public holidays. The change replaces manual calculations with a safer method that correctly accounts for global holidays, ensuring accurate overtime reporting.
Original PR description
Currently, flexible weekly overtime deducts the raw leave interval duration. ## **Steps to reproduce:** - Install hr_holidays and hr_attendance - Create an employee with flex 40h/week working…
Currently, flexible weekly overtime deducts the raw leave interval duration. ## **Steps to reproduce:** - Install hr_holidays and hr_attendance - Create an employee with flex 40h/week working schedule. - Employee profile>setting>Default Ruleset>Employee schedule Rule and set `If the worked hours on a`: `week`. - Create a public holiday on Monday. - Record daily 8h from Tue to Sat (12 AM to 8 AM). ## **Observed Behavior:** Attendance List View computes "Worked Extra Hours" incorrectly as 20:30h ## **Expected Behavior:** "Worked Extra Hours" should be computed as 8h ## **Root Cause:** In [_get_daterange_overtime_undertime_intervals_for_quantity_rule](https://github.com/odoo/odoo/blob/53448e5445c8bcbf12126bf27bd675f4b9883d05/addons/hr_attendance/models/hr_attendance_overtime_rule.py#L290-L342), the system manually calculates overtime for flexible employees by deducting `schedule['leave']` durations from the expected working hours at [1]. However, for global public holidays, the system mishandles the timezone conversion within this schedule dictionary. Because public holiday intervals are stored and processed using UTC datetimes before being converted to the employee's local timezone, converting it to the employee's local timezone causes the holiday hours to shift and overlap into the next calendar day. As a result, the `schedule['leave']` calculation incorrectly thinks the employee had time off on normal working days, which throws off the final overtime amount. [1]: http://github.com/odoo/odoo/blob/53448e5445c8bcbf12126bf27bd675f4b9883d05/addons/hr_attendance/models/hr_attendance_overtime_rule.py#L304-L307 ## **Fix:** Replace the manual leave subtraction logic with the existing `_get_expected_hours_from_contract` method. This method naturally handles global public holidays and computes attendance intervals safely across different timezones without shifting hours into the wrong day. **opw-6259328,6284145** Forward-Port-Of: odoo/odoo#269293
This update resolves an issue where attachments were incorrectly flagged as 'unsupported' when using non-UBL sending methods. The fix also corrects a minor typo, ensuring accurate attachment identification. This improves the reliability of UBL invoice sending.
Original PR description
In the send wizard, don't mark attachments as "unsupported" if the sending method is not ubl dependent Also fix a typo in "Unspported" no-task Forward-Port-Of: odoo/odoo#275301
This update streamlines the verification of EU VAT numbers during company creation. Previously, a redundant check was performed twice, impacting performance. This change consolidates the verification process to a single call, optimizing efficiency and reducing potential service limitations.
Original PR description
When we create a company with a EU VAT, we used to do 2 IAP call to verify the VAT number. One was on the create() and the other one on the write(). For performance reason and because the vies check service may limit ip address, the verification was already disable when importing files (in both create and write). This commit remove the compute on the create one (and keep the one on write), so that it only do 1 IAP call to verify the VAT. Task-6139346 Forward-Port-Of: odoo/odoo#275456 Forward-Port-Of: odoo/odoo#274644
This update fixes an issue where employees were incorrectly showing zero remaining days off after receiving allocated time. The fix ensures that the system accurately reflects available leave balances by correctly passing the target date through the calculation process, even when operating under sudo contexts.
Original PR description
Bug : - Create a new employee (also works with old employees) - Create an allocation of Paid Time Off that is available in the future. - Create a Time Off request for this employee in the future. -…
Bug : - Create a new employee (also works with old employees) - Create an allocation of Paid Time Off that is available in the future. - Create a Time Off request for this employee in the future. - When Selecting Time off type you'll see that he has (0 remaining out of 0 days) even though he has just be allocated leaves. Reason : clicking on the many2one field => triggers web_name_search (line 53 in web/models/modeld.py) => triggers name_search (line 1514 in orm/models.py) , here we fetch the searched records with sudo , and when switching to sudo we call a function called clean_context this function (line 952 in odoo/tools/misc.py) remove elements from the context that start with the prefix default_ , in our case , we when clicking on the field we pass the target date through default_date_from , thus we lose it , and instead we make the calculations as if the target date was today Fix : pass the date_from through 'leave_date_from' given that _ compute_leaves already checks this context entry, this way we make sure to keep our start_date in the context even if we switch to sudo during some point in the calculation. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#273670
This update resolves an issue where the session fingerprint verification process could fail, preventing users from correctly authenticating on certain devices. The fix ensures that errors during identity checks are handled properly, maintaining the system's ability to verify user identity and preventing form mounting on untrusted devices. This improves overall security and reliability.
Original PR description
This commit introduce two corrections. A. Since commit[^1], it is not necessary to check the fingerprint at the start of the service. It is the first `CheckIdentityException` which will trigger the…
This commit introduce two corrections. A. Since commit[^1], it is not necessary to check the fingerprint at the start of the service. It is the first `CheckIdentityException` which will trigger the verification mechanism and, as a result, will update or check the fingerprint. The first request to a auth route will initialize the "bootstrapping" of the session fingerprint. B. The function `updateFingerprint` must return a negative response if an error occurs and thus continue the verification process (which requires that the system not be offline). For information, we cannot ignore an error. This is because the original RPC will be replayed (without the wrapper that handles the `CheckIdentityException` exception). It is therefore necessary to remain in a state where the user can verify his identity. This fix solved an undesirable side effect. The update of the fingerprint according to the event `WEB_CLIENT_READY` occurs at an arbitrary time. If a form is currently being mounted (because an untrusted device is being used) but the fingerprint update marks that device as trusted in the backend (no matter the reason), then when we call `/web/session/identity/check` without any data to retrieve the reauthentication methods, the fingerprint check method will no longer be possible[^2]. As a result, the form is mounted for a trusted device (and not perform fingerprint check). [^1]: https://github.com/odoo/odoo/commit/a43dee53f103f8ce19e5c84ca7d515e2a27e03ff [^2]: https://github.com/odoo/odoo/blob/7c6f31d730304bca3f6c996800e76d1e40ce4adf/odoo/addons/base/models/ir_http.py#L563 Task-6373219
This update fixes an issue where a new database index wasn't being utilized by Odoo's internal queries. The change ensures the index works correctly with both custom queries and those generated by the Odoo ORM, leading to faster data retrieval. This improves overall system performance.
Original PR description
The index added by 778c09f4ffb4 works for the specific query it was meant to improve. Unfortunately, it cannot be used by ORM-generated queries, which is unfortunate. The reason is that the ORM generates queries with `IS TRUE` or `IS NOT TRUE` for boolean fields. Because `=` and `IS` do not have the same semantics, postgresql cannot use the index for ORM-generated queries. = -> eval(NULL = True) -> NULL IS -> eval(NULL IS TRUE) -> FALSE By changing both the index and the query to use `IS TRUE`, the index is now used by both the specific query and the ORM. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a visual inconsistency in the website's accordion controls. Previously, the accordion's color was applied inconsistently between its expanded and collapsed states. This fix ensures a consistent and professional appearance for all users.
Original PR description
In commit[1] we restyled the accordion snippets, removing the background-image to use oi-icons instead. However due to selector specificty, the rule was taking priority. This :not is actually wrong since we want the color to apply as well when the accordion is collapsed (else you have 2 different colors between the collapsed uncollapsed state) task-6361379 [1]: f26a1535b96c728e4360d94c0c06de138a6b1b3f --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#274577 Forward-Port-Of: odoo/odoo#274016
This update corrects a bug that prevented the correct generation of KSeF invoices for service down payments with 0% EU VAT. The fix ensures the necessary 'P_13_9' field is included in the exported XML, complying with Polish tax regulations. This ensures accurate reporting and avoids potential issues with tax authorities.
Original PR description
_**Steps to reproduce:**_ * Install `l10n_pl_edi` and enable **Allow KSeF integration** from Accounting settings. * Switch to a Polish company. * Create an EU customer with a valid VAT number. *…
_**Steps to reproduce:**_ * Install `l10n_pl_edi` and enable **Allow KSeF integration** from Accounting settings. * Switch to a Polish company. * Create an EU customer with a valid VAT number. * Create a sale order containing a service product taxed with **0% EU S**. * Confirm the sale order and create a down payment invoice. * Send the invoice to KSeF and inspect the generated XML. **_Observed behavior:_** * The generated KSeF XML does not contain the `P_13_9` field. **_Cause:_** * For down payment invoices involving services taxed with **0% EU S**, the value corresponding to `P_13_9` was not being assigned during XML generation, causing the tag to be omitted from the exported KSeF document. **_Fix_**: * Populate the value of `P_13_9` during KSeF XML generation for service down payment invoices, ensuring the field is correctly included in the exported XML. * This PR updates the computation of tag `P_13_10` to ensure consistency with the expected reporting logic, where the tag is computed solely from `K_31`. Here is the [Documentation](https://ksef.podatki.gov.pl/media/gtjhkeek/information-sheet-on-the-fa-3-logical-structure-04032026.pdf) link for the reference of the Ksef structure. opw-6294181 Forward-Port-Of: odoo/odoo#270986
12 changes
Resolved issues and error corrections
This update resolves several issues within the HTML editor's file box functionality. Specifically, it prevents the powerbox from opening within file boxes, ensures plain text is pasted correctly, and corrects a visual bug related to scrollbars. These changes enhance usability and stability when working with files in the editor.
Original PR description
### Purpose of this PR: * Prevent the powerbox from opening inside a static file box. * Paste content as plain text inside a static file box, since formatting is not supported there. * Prevent the cursor from leaving an empty file name box when pressing `ArrowLeft` or `ArrowRight`. * o_we_preview_favicon had a fixed height larger than its content, causing the link popover to overflow and show an unwanted scrollbar when the file input was empty as there was nothing to preview. Reduced the height to match the actual content size. * Shorthands (such as `#` for headings or `*` for lists) should not trigger when editing inside a file box. task-6283420 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#275308 Forward-Port-Of: odoo/odoo#268827
This update fixes an issue where the amount to invoice was incorrectly calculated when products were ordered using a Unit of Measure (UoM) like 'pack of 6'. The fix ensures that invoice amounts accurately reflect the quantity and UoM of purchased goods, improving accounting accuracy.
Original PR description
**PROBLEM** amount_to_invoice_at_date is not calculated correctly when using UoM. **STEP TO REPRODUCE** 1. Create a product tracked by unit. 2. Create a purchase order with a UoM of pack of 6 (or some multiples of the Units UoM). 3. Confirm the PO and receive the products. 4. Go to the accounting app, reviews>bill to receive 5. Notice the po line on bill to receive as an incorrect amount. opw-6305324 Forward-Port-Of: odoo/odoo#270327
This update fixes an issue where the 'Load Demo Data' button in the Employee app would overflow text when the app was set to French or Arabic. The fix automatically adjusts the button's width to fit the text, ensuring a clean and consistent user experience. This improves readability and usability for all users.
Original PR description
Steps to reproduce: ---------------------------------------- - Be in a company with no employees - Switch to French or Arabic - Open the Employee app - The text in the button overflows Cause: ---------------------------------------- The button has a specified width: `w-100` And the text is `text-nowrap` So it overflows from the button box Solution: ---------------------------------------- Make the width auto adapt to the text with `w-auto`. Before: <img width="727" height="201" alt="image" src="https://github.com/user-attachments/assets/0347125b-1595-44ea-a0bd-b7c77e6c753d" /> After: <img width="723" height="236" alt="image" src="https://github.com/user-attachments/assets/18e40b39-f7b9-488c-9e47-3b9b82bdb445" /> opw-6345094 Forward-Port-Of: odoo/odoo#274405
This update resolves an issue where attachments were incorrectly flagged as 'unsupported' when using non-UBL sending methods. The fix also corrects a minor typo, ensuring accurate attachment identification. This improves the reliability of UBL invoice sending.
Original PR description
In the send wizard, don't mark attachments as "unsupported" if the sending method is not ubl dependent Also fix a typo in "Unspported" no-task Forward-Port-Of: odoo/odoo#275301
This update fixes an issue where employees were incorrectly showing as having zero remaining holiday days after being allocated time off. The fix ensures that the system accurately reflects available holiday balances by correctly passing the allocation date through the calculation process, even when running under sudo.
Original PR description
Bug : - Create a new employee (also works with old employees) - Create an allocation of Paid Time Off that is available in the future. - Create a Time Off request for this employee in the future. -…
Bug : - Create a new employee (also works with old employees) - Create an allocation of Paid Time Off that is available in the future. - Create a Time Off request for this employee in the future. - When Selecting Time off type you'll see that he has (0 remaining out of 0 days) even though he has just be allocated leaves. Reason : clicking on the many2one field => triggers web_name_search (line 53 in web/models/modeld.py) => triggers name_search (line 1514 in orm/models.py) , here we fetch the searched records with sudo , and when switching to sudo we call a function called clean_context this function (line 952 in odoo/tools/misc.py) remove elements from the context that start with the prefix default_ , in our case , we when clicking on the field we pass the target date through default_date_from , thus we lose it , and instead we make the calculations as if the target date was today Fix : pass the date_from through 'leave_date_from' given that _ compute_leaves already checks this context entry, this way we make sure to keep our start_date in the context even if we switch to sudo during some point in the calculation. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#273670
This update fixes an issue where the ECPay payment portal displayed in simplified Chinese when Odoo was set to traditional Chinese. The fix ensures the portal correctly displays in traditional Chinese (zh_TW), aligning with user locale settings and improving the checkout experience for Taiwanese customers. This resolves a misconfiguration in the language mapping.
Original PR description
…chinese ## Current behavior: When Odoo locale is set in traditional Chinese (zh_TW), the ECPay payment portal shows up in simplified Chinese (zh_CN). ## Expected behavior: When Odoo locale is set in…
…chinese ## Current behavior: When Odoo locale is set in traditional Chinese (zh_TW), the ECPay payment portal shows up in simplified Chinese (zh_CN). ## Expected behavior: When Odoo locale is set in traditional Chinese (zh_TW), the ECPay payment portal should show up in traditional Chinese (zh_TW) also. ## Steps to reproduce: In Odoo 19.0, 1. Install modules: payment_ecpay, website, ecommerce 2. Change the company and website language to Traditional Chinese (zh_TW). Make sure the currency is in TWD (Taiwanese Dollar) 3. Add ECPay as a payment method 4. Add some test products and checkout with ECPay 5. Observe the language on ECPay portal website, and payload in V5 package in network tab ## Cause of the issue: Initially the locale mapping was wrong, mapping CHI to zh. There's no "zh" locale, must either be "zh_TW" or "zh_CN". So when the Odoo locale is set to traditional Chinese (zh_TW), it included Language=CHI in the payload and redirect to ECPAY, making ECPay think that we're trying to request the simplified Chinese site. Caused by commit: 76c81d6f67b54940879b1020068c7140c4f2199b ## Fix: Fixed the language mapping following ECPay developer docs, and what language code to be included in the payload sent to ECPay from current Odoo locale. opw-6270820 --------------------------------------------------------------- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#269206
This update fixes an issue where the HTML editor was incorrectly triggering font size checks even when users applied other formatting styles. Now, list item font size checks are limited to font size formatters only, ensuring a smoother and more reliable editing experience. This improves the overall stability and usability of the HTML editor.
Original PR description
#### Description of the issue this PR addresses: - Fully selected list items could go through font size checks even when applying unrelated formatters. #### Desired behavior after PR is merged: - Restrict list item font size checks to font size formatters only. task-6329161 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#275096 Forward-Port-Of: odoo/odoo#272104
This update corrects a visual inconsistency in the website's accordion controls. A previous change caused the accordion to have different colors when expanded versus collapsed. This fix ensures a uniform and professional appearance for all users, regardless of the accordion's state.
Original PR description
In commit[1] we restyled the accordion snippets, removing the background-image to use oi-icons instead. However due to selector specificty, the rule was taking priority. This :not is actually wrong since we want the color to apply as well when the accordion is collapsed (else you have 2 different colors between the collapsed uncollapsed state) task-6361379 [1]: f26a1535b96c728e4360d94c0c06de138a6b1b3f --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#274577 Forward-Port-Of: odoo/odoo#274016
This update fixes an issue where Polish service downpayment invoices weren't including a required field (`P_13_9`) in the KSeF XML export. The fix ensures that these invoices now correctly generate the necessary XML for tax reporting, addressing a compliance requirement. This impacts businesses using the l10n_pl_edi module for VAT reporting in Poland.
Original PR description
_**Steps to reproduce:**_ * Install `l10n_pl_edi` and enable **Allow KSeF integration** from Accounting settings. * Switch to a Polish company. * Create an EU customer with a valid VAT number. *…
_**Steps to reproduce:**_ * Install `l10n_pl_edi` and enable **Allow KSeF integration** from Accounting settings. * Switch to a Polish company. * Create an EU customer with a valid VAT number. * Create a sale order containing a service product taxed with **0% EU S**. * Confirm the sale order and create a down payment invoice. * Send the invoice to KSeF and inspect the generated XML. **_Observed behavior:_** * The generated KSeF XML does not contain the `P_13_9` field. **_Cause:_** * For down payment invoices involving services taxed with **0% EU S**, the value corresponding to `P_13_9` was not being assigned during XML generation, causing the tag to be omitted from the exported KSeF document. **_Fix_**: * Populate the value of `P_13_9` during KSeF XML generation for service down payment invoices, ensuring the field is correctly included in the exported XML. * This PR updates the computation of tag `P_13_10` to ensure consistency with the expected reporting logic, where the tag is computed solely from `K_31`. Here is the [Documentation](https://ksef.podatki.gov.pl/media/gtjhkeek/information-sheet-on-the-fa-3-logical-structure-04032026.pdf) link for the reference of the Ksef structure. opw-6294181 Forward-Port-Of: odoo/odoo#270986
This update resolves an issue where the 'Contact Us' button on product pages wasn't correctly redirecting to snippets when a zero-price product was created. The fix ensures that anchor links in the button URL are properly processed, allowing users to navigate to the intended snippets as expected. This improves the user experience for product pages.
Original PR description
Issue: ------- When a zero price product is created and the contact us button on the product page is intended to redirect to some snippets created through drag and drop then the button doesn't work…
Issue: ------- When a zero price product is created and the contact us button on the product page is intended to redirect to some snippets created through drag and drop then the button doesn't work as intended meaning it doesn't redirects to the desired snippet even after putting the correct anchor. for ex: `#snippet-anchor` in the `Button URL` field in the settings. Cause: -------- This works fine for the pages having '/contactus' or '/'. Issues raise only when we try to redirect to a snippet. Now, if the we try to redirect to any snippet on click of the button(Contact Us) by placing the corresponding anchor, it will not redirect/work as intended. This is because of the appending`?subject=product_name` that took place. Solution: ------------ To concatenate the `subject=product_name` conditionally if the url has '#' in it If yes, we just use the `url` in the URL so that it redirects as intended else concatenate the subject & so on. This is because for redirecting to snippets we use anchors such as '#Let's-Connect'. So, In an anchor the '#' will definitely reside. Steps to reproduce: ----------------------- 1. Create a db in version 18.3 with website_sale installed. 2. Enable the `Prevent Sale of Zero Priced Product` checkbox in the settings. 3. Create a zero price product and few snippets under it and copy the anchor of one of the snippets to redirect when clicked on the 'Contact Us' button. 4. Use the Anchor(for ex: '#Let's-Connect') in the 'Button URL' field of settings. 5. Navigate to the created product and click on the 'Contact Us' button. Nothing happens & no intended redirection to the desired snippet. Ref PR: ---------- https://github.com/odoo/odoo/pull/189049/changes#diff-39e02d03a8b765b4e3afc68627aeb33f11b587163638fedfb92ed5657c3336e7R398-R399 Attachments: ----------------- **Before Fix:** [vokoscreenNG-2026-02-06_17-36-37.webm](https://github.com/user-attachments/assets/a09101d4-13df-415d-a902-420a28aedef0) **After Fix**: [vokoscreenNG-2026-02-06_17-38-37.webm](https://github.com/user-attachments/assets/a6256d0f-d8cb-4146-b95e-33452a0a79c5) - OPW - [5494517](https://www.odoo.com/odoo/project/70/tasks/5494517) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249110 Forward-Port-Of: odoo/odoo#247587
This update fixes an issue where template tasks were incorrectly counted in task lists and views. The change ensures that task counts and views accurately reflect only real subtasks, improving the clarity and accuracy of project task management, particularly for tasks created using templates.
Original PR description
Steps to Reproduce --- - Create a normal parent task with one normal sub-task and one template sub-task. - Open the parent task form view and observe the Sub-tasks stat button count and notebook tab,…
Steps to Reproduce --- - Create a normal parent task with one normal sub-task and one template sub-task. - Open the parent task form view and observe the Sub-tasks stat button count and notebook tab, check the subtask view as well. - Create a template parent task with one normal sub-task and one template sub-task, then repeat the same checks. Issue --- - Task templates are handled like regular subtasks in the subtask count, notebook, and subtask view, without taking the parent task type into account. Current Behaviour --- - For a normal parent task, both the normal sub-task and the template sub-task are counted and shown in the opened subtask view and notebook. - For a template parent task, the same filtering is applied, even though template subtasks should remain accessible in that context. Expected Behaviour --- - For a normal parent task, only real sub-tasks should be counted and shown in the subtask view and notebook, and on the project kanban card. - For a template parent task, template subtasks should remain available in the subtask view and notebook according to the parent template context. - In the project kanban card, tasks must not be counted when their parent task is a template, even if the child task itself is not a template. Fix --- - Apply template-aware filtering to subtask counting,project kanban task count and subtask view behavior, depending on whether the parent task is a normal task or a template task. task-5966684 Forward-Port-Of: odoo/odoo#274590 Forward-Port-Of: odoo/odoo#252403
Features or functions removed from Odoo
This update refines the way payment lines are handled within the restaurant POS module. The team has switched to a more modern, camelCase naming convention for payment methods, enhancing the system's internal structure and aligning with current development standards. This change ensures smoother and more efficient payment processing.
Original PR description
In this commit: - Use the new method names in the payment adjustment flow. - Replace deprecated snake_case methods with their camelCase equivalents for payment lines, payment terminals, and order totals. Task:6049128 Forward-Port-Of: odoo/odoo#271792
8 changes
Resolved issues and error corrections
This update resolves an issue where attachments were incorrectly flagged as 'unsupported' when using non-UBL sending methods. The fix also corrects a minor typo, ensuring accurate attachment handling within the account EDI process. This improves the reliability of sending invoices.
Original PR description
In the send wizard, don't mark attachments as "unsupported" if the sending method is not ubl dependent Also fix a typo in "Unspported" no-task Forward-Port-Of: odoo/odoo#275301
This update clarifies the terminology used in Odoo's overtime reporting by renaming confusing labels like 'Difference' and 'Balance' to 'Worked Extra Hours' and 'Validated Extra Hours'. This change ensures consistent and understandable reporting across all views, improving data accuracy and user experience.
Original PR description
The reporting labels "Difference" and "Balance" are confusing because "Difference" tracks system-qualified overtime while "Balance" represents accepted overtime hours. There is also a lack of consistency across views. This commit renames these fields to "Worked Extra Hours" and "Validated Extra Hours" to harmonize the naming everywhere task-6352142 Description of the issue/feature this PR addresses: Confusing and inconsistent naming for extra hours Current behavior before PR: - Reporting uses "Difference" and "Balance". - Views use inconsistent labels. Desired behavior after PR is merged: Labels are consistently named "Worked Extra Hours" and "Validated Extra Hours" everywhere. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#274097 Forward-Port-Of: odoo/odoo#273631
This update corrects a visual inconsistency in the website's accordion controls. A recent change improved the design by using icons instead of background images, but a specific rule was overriding the intended color styling. This fix ensures the accordion has a consistent color appearance regardless of whether it's expanded or collapsed, improving the overall user experience.
Original PR description
In commit[1] we restyled the accordion snippets, removing the background-image to use oi-icons instead. However due to selector specificty, the rule was taking priority. This :not is actually wrong since we want the color to apply as well when the accordion is collapsed (else you have 2 different colors between the collapsed uncollapsed state) task-6361379 [1]: f26a1535b96c728e4360d94c0c06de138a6b1b3f --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#274016
This update corrects a bug that prevented the correct KSeF XML files from being generated for downpayment invoices related to services with 0% EU VAT. The fix ensures all necessary data is included in the exported invoice, complying with Polish tax regulations. This ensures accurate reporting to the KSeF system.
Original PR description
_**Steps to reproduce:**_ * Install `l10n_pl_edi` and enable **Allow KSeF integration** from Accounting settings. * Switch to a Polish company. * Create an EU customer with a valid VAT number. *…
_**Steps to reproduce:**_ * Install `l10n_pl_edi` and enable **Allow KSeF integration** from Accounting settings. * Switch to a Polish company. * Create an EU customer with a valid VAT number. * Create a sale order containing a service product taxed with **0% EU S**. * Confirm the sale order and create a down payment invoice. * Send the invoice to KSeF and inspect the generated XML. **_Observed behavior:_** * The generated KSeF XML does not contain the `P_13_9` field. **_Cause:_** * For down payment invoices involving services taxed with **0% EU S**, the value corresponding to `P_13_9` was not being assigned during XML generation, causing the tag to be omitted from the exported KSeF document. **_Fix_**: * Populate the value of `P_13_9` during KSeF XML generation for service down payment invoices, ensuring the field is correctly included in the exported XML. * This PR updates the computation of tag `P_13_10` to ensure consistency with the expected reporting logic, where the tag is computed solely from `K_31`. Here is the [Documentation](https://ksef.podatki.gov.pl/media/gtjhkeek/information-sheet-on-the-fa-3-logical-structure-04032026.pdf) link for the reference of the Ksef structure. opw-6294181 Forward-Port-Of: odoo/odoo#270986
This update resolves an issue that prevented importing large Peppol invoices due to a technical error in the underlying XML parsing library. The fix involves pre-processing the invoice data to remove problematic elements, ensuring smoother and more reliable invoice imports. This improves the system's ability to handle a wider range of Peppol invoice formats.
Original PR description
### Description: When importing a Peppol invoice containing a massive embedded attachment, the `lxml` library throws an `lxml.etree.XMLSyntaxError: huge text node` error. This is a built-in safety check in libxml2 designed to prevent DoS attacks via XML entity expansion or malicious bombs [^1]. Rather than disabling this security protection globally using the `huge_tree` parser flag, we pre-process and trim the raw XML to remove the heavy binary nodes before parsing. ### References: opw-6085893 [^1]: https://lxml.de/6.0/FAQ.html#is-lxml-vulnerable-to-xml-bombs Forward-Port-Of: odoo/odoo#275367
This update fixes an issue where images weren't displaying correctly in Outlook emails. The change backports a previous fix to ensure that all users, especially those who rely on Outlook, receive images properly. This improves email communication and reduces potential customer frustration.
Original PR description
Backport the changes from `b9370ea6b70ca3020c73a6940d70ff0cf954f69f` into `mail/convert_inline` to ensure Outlook-compatible image rendering. opw-3776054 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#269436
A recent test failure was caused by an incorrect calculation of holiday allocations in our Odoo system. This update adds a 'freeze_time' to the system for a specific date, ensuring that holiday calculations accurately reflect the intended accrual rules, particularly in future builds. This prevents over-allocation of holiday days.
Original PR description
Problem ------------------------ test_department_accrual_allocation was failing due to the allocation being calculated as 26 days instead of 21 in faketime builds set to 2027. This was because the accrual plan was set to accrue 21 days per year and carry over 5 days from the previous year. Since the allocation was created on Jan 1st 2026, all 2027 builds were calculating the allocation to have 5 extra days. Solution ---------------------- Added freeze_time for 2026-03-01 to ensure the date stays the same. runbot-939344 task-6344033 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#272728
Features or functions removed from Odoo
This update simplifies the way payment lines are handled within the restaurant POS module. The team has switched to a more modern naming convention (camelCase) for payment methods, improving code clarity and maintainability. This change ensures the system continues to function smoothly and efficiently.
Original PR description
In this commit: - Use the new method names in the payment adjustment flow. - Replace deprecated snake_case methods with their camelCase equivalents for payment lines, payment terminals, and order totals. Task:6049128
8 changes
Enhancements to existing features
The editor now hides link-creating shortcuts when users are editing labels or buttons, where links can interfere with the expected click behavior. This reduces the chance of creating content that behaves unpredictably in appointments, documents, or knowledge articles.
Original PR description
*: appointment, documents, knowledge When a `<label>` element is clicked it should be like a click in the related input. For `button` it should activate its action. If there is a link in the label or button, it will handles clicks inside of it. Thus we want to discourage the user from adding links in label or buttons elements. Tools inserting links remove the surrounding link, thus we disable those tools inside links. This commit affects the availability of: - "Insert a file from Documents" in powerbox - "Insert an Article shortcut" in powerbox - "Add a specific appointement" in powerbox task-4860229
Saudi payroll run reports now show Total Cost based on net cost and replace the gross section with Total GOSI Contribution. This gives payroll teams clearer, localization-specific totals for reviewing employer and employee social insurance costs, with tests added to protect the calculation.
Original PR description
[IMP] l10n_sa: adjustments in costs of payrun
For Saudi Localization:
1 - In payrun costs section, the label of employer cost became Total Cost and its value became NETCOST (We show the sum of NETCOST in there)
2 - Gross section is removed and we are showing Total GOSI Contribution and its value is the summation of abs(GOSI_COMP) + abs(GOSI_EMP)
task - 6326336Belgian payroll now uses one company number field instead of multiple overlapping entries, reducing confusion during setup. Existing data is preserved during upgrade, and DMFA reporting uses the same BCE company number consistently.
Original PR description
The Belgian payroll configuration exposed three overlapping "numbers" that were confusing and poorly documented: - ONSS Company ID (onss_company_id) - ONSS Registration Number (onss_registration_number) - Company Number (l10n_be_company_number) `onss_company_id` was labelled "ONSS Company ID" but its tooltip described the BCE (Crossroads Bank for Enterprises) enterprise number, and its placeholder looked like an ONSS matricule. It was in fact a redundant duplicate of `l10n_be_company_number`: in the DMFA, the <CompanyID> element is the BCE enterprise number. Remove the redundant `onss_company_id` field and make `l10n_be_company_number` the single source of truth, including for the DMFA <CompanyID>. Document it with the help "A 10 digits number issued by BCE" and surface the Company Number in the payroll settings page. Data is preserved in an upgrade script: where the two values differ, `onss_company_id` is copied into `l10n_be_company_number`. task-6352367
Resolved issues and error corrections
This update corrects how Belgian CODA bank statement data is read after a recent compatibility change. It prevents import errors or incorrectly structured statement data, helping accounting teams continue processing bank files reliably.
Original PR description
In this commit: https://github.com/odoo/enterprise/commit/54ff6637af96533e7f035eeff84f79336dc4650b we made a fix because thanks to this commit:https://github.com/odoo/enterprise/commit/c66995fda83e19b28a38312af8efdc1601881cf0 where we did a backport of the extension number. The backport adds the extension number to the return of the _parse_bank_statement_file. With that we have 4 args returned. Without the * we would have the "too many value to unpack" error. But when doing that we miss to change the stmt_vals = data to take the last element. Otherwise, we will have a list of two elements. no task id Forward-Port-Of: odoo/enterprise#124019
This fix ensures a UAE payroll employee skill level field is only visible to HR users. It prevents non-HR employees from seeing HR-specific information on public employee profiles, improving privacy and access control.
Original PR description
add group `hr.group_hr_user` to `l10n_ae_mohre_skill_level` to make sure it's hidden for non-hr users in the public employee profile fixes https://runbot.odoo.com/odoo/error/242024 opw-242024
This fixes the setup used to import ONSS rates for Belgian payroll. It helps ensure payroll calculations use the correct social security rate configuration, reducing the risk of incorrect payroll processing.
Original PR description
task-6370115
Attendance administrators without Payroll or Employees permissions can now open the Attendances app and view overtime rule details without access errors. This ensures the right managers can manage attendance-related settings without needing broader employee or payroll access.
Original PR description
Issue ======== Currently, a user with Attendances administration rights and no Payroll/Employees rights is unable to access the app attendances, and even inside the app, they cannot view the individual rules of the Overtime Rulesets menu. Fix ======== - Allow attendance admins to access `hr.version` fields (`contract_date_start` and `contract_date_end`) with the new custom group rights created in `hr` and `hr_attendance`, to prevent access errors when viewing overtime rules. TaskID-6128198
Code cleanup and technical improvements
This update tidies how Odoo Enterprise apps declare their internal dependencies, removing unnecessary entries while making special connector dependencies explicit. For normal installations, the same apps will be installed as before, but the setup is clearer and more predictable in advanced installation modes.
Original PR description
Rework the `depends` of the manifests so that every dependency that can be implicit is implicit; and make explicit the glue ones whose whole dependency closure was already part of the module's one, instead of the dependencies they subsume. Community PR: https://github.com/odoo/odoo/pull/275398
22 changes
New functionality added to Odoo
Adds the required Latvian VAT report attachments and an XML export that includes both the main report and attachment details. This helps Latvian businesses prepare more complete VAT submissions with transaction breakdowns for purchases, sales, EU transactions, and applicable aggregation rules.
Original PR description
This commit adds 4 attachments to the Latvian tax report and an XML export for the tax report (including the attachments). The attachments are the following - PVN 1-I: domestic purchase / import -…
This commit adds 4 attachments to the Latvian tax report
and an XML export for the tax report (including the attachments).
The attachments are the following
- PVN 1-I: domestic purchase / import
- PVN 1-II: EU purchase
- PVN 1-III: domestic sales / export
- PVN 2: EU sale
The attachments give more details for the tax report.
The lines of the attachments are "transactions"
A "transaction" is identified by the move and the transaction type or document type.
The transaction type is given via a tax tag (see community PR).
- PVN 1-I: transaction type, move
- Small transactions (< 150€) are aggregated separately under transaction types 'V' or 'T'
independently of the move
- 'V': All small transactions of a partner in case the total of all their small transactions reaches 150€
- There is max 1 line per partner
- 'T': All small transactions that are not grouped under some 'V' line
- There is max 1 line like this; it has no partner information
- PVN 1-II: transaction type, move
- Small transactions (< 150€) are aggregated separately under transaction types 'V' or 'T'
(like PVN 1-I)
- PVN 1-III: document type, move and line in the main tax report
- All transactions with (document) type 'X' are aggregated on a single line
- Small transactions (< 150€) are aggregated separately under document types 'V' or 'T'
(like PVN 1-I)
- The line in the main tax report is ignored for 'X' and small transactions
- PVN 2: transaction type, move
- No aggregation is performed here
Only account move lines that are tagged with a transaction type (1-I, 1-II, 2)
or a relevant tag for the main report (1-III) are shown in the reports.
The tags `Rep` and `C (car)` only take 40% and 50% respectively of the
base amounts. The tax amount is assumed to be split correctly.
task-4251184
Forward-Port-Of: odoo/enterprise#84135Enhancements to existing features
This change avoids confusion around inventory valuation settings by addressing a periodic valuation option that does not apply as expected for perpetual valuation. It helps users avoid expecting closing entries that are not generated under that setup, while the final behavior is being handled in the related core update.
Original PR description
Problem: The Periodic Valuation frequency has no effect when the valuation method is Perpetual, since the Inventory Valuation Closing only runs for the Periodic method. This can confuse users into expecting a periodic closing entry that is never generated. Solution: Following the review feedback, the intended behavior is for the closing cron to also run for Perpetual companies so their valuation stays continuously updated. The fix therefore moves to the community cron instead of hiding the field: superseded by odoo/odoo#275955.
Mexican payroll CFDI validation has been updated to match version 1.2e requirements. This helps payroll teams generate compliant electronic payslip records by checking taxable and exempt income values per line and applying the latest subsidy limits.
Original PR description
**. Perceptions – ImporteGravado / ImporteExento (XML Nodes)** For each Perception node, validate that: If ImporteExento = 0, then ImporteGravado > 0. If ImporteGravado = 0, then ImporteExento > 0. Both values cannot be 0 at the same time. These validations must be applied per Perception node, not at an aggregated level. **. TipoPercepcion = "038" (Other Salary Income) (XML Nodes)** When TipoPercepcion = "038": ImporteExento must always be 0. The amount must be recorded only in ImporteGravado. **. SubsidioCausado (XML Nodes)** Update the validation logic for the SubsidioCausado attribute based on NumDiasPagados: If NumDiasPagados ≤ 31, SubsidioCausado ≤ 628.00 If NumDiasPagados > 31, SubsidioCausado ≤ NumDiasPagados × 0.206 task-5412728
Signature requests created from other apps now include the document template name alongside the related record. This makes request names, file names, and email subjects easier to recognize and less likely to be confused with the signer’s name.
Original PR description
When requesting a signature from another app, the request name, filename and email subject only showed the linked record name, which often read as the signer's name. The template name is now added so all three follow the same "<prefix> - <template> - <record>" format. task-6317174
Resolved issues and error corrections
Chilean export invoice PDFs now keep customs information in the correct columns even when origin or destination port details are missing. This prevents package quantities and other export details from appearing under the wrong headings, improving document accuracy for customers and compliance workflows.
Original PR description
### Issue: On Chilean export invoices, the customs information table may display data in the wrong columns When `Origin Port` or `Destination Port` is not set, the corresponding `td` is omitted by…
### Issue: On Chilean export invoices, the customs information table may display data in the wrong columns When `Origin Port` or `Destination Port` is not set, the corresponding `td` is omitted by QWeb, causing the remaining columns to shift left This results in `Qty of Packages` appearing under `Origin Port` or `Destination Port` in the printed document ### Cause: `l10n_cl_port_origin_id` and `l10n_cl_port_destination_id` have no default value and are optional fields `t-out` on a falsy value omits the `td` entirely in QWeb, breaking the column alignment Adding `or ''` ensures an empty `td` is always rendered, preserving the table structure regardless of whether the fields are set ### Steps to reproduce: - Install `l10n_cl_edi_exports` and switch to CL Company - Create an Invoice (any customer, any line) - In the gear menu, select Print > Invoice PDF copy (Chile) Before the fix, `Qty of Packages` appears under `Origin Port` when neither port field is set opw-6304670 Forward-Port-Of: odoo/enterprise#121923
This fix prevents accounting screen filters from accidentally carrying over into document creation and causing errors. Users can update invoice payments from accounting workflows more reliably, including Mexican CFDI payment updates.
Original PR description
**Issue:** The `default_type` context can leak into documents during creation with invalid values (e.g., 'sale' for documents.document.type), causing a ValueError. **Steps to reproduce - using MX EDI update payment:** - Use a Mexican company with CFDI credentials configured. - Create an invoice "payment policy = PPD", and send it to CFDI. - Create a bank transaction and reconcile it with the invoice. - Go to the Accounting Dashboard, remove current filters, and group by "Type" (this injects default_type into the context). - From there, enter the "Sales" journal and open the invoice. - Click on the "Update Payments" button. - Result: `ValueError: Wrong value for documents.document.type: 'sale'` **Fix:** Clean context from the `default_*` keys when transitioning from Accounting to Documents models. opw-6141172 opw-5742850 opw-6182877
Canadian EFT export files now include a nonzero item trace number for each payment, using the payment's own identifier. This helps ensure CPA-005 payment files meet Canadian banking requirements and reduces the risk of rejected transactions.
Original PR description
Issue: The Item Trace Number according to CPA-005 standard should be a nonzero sequence that serves as unique reference ID for payments. Currently, Odoo sets the Item Trace Number of all payments as…
Issue: The Item Trace Number according to CPA-005 standard should be a nonzero sequence that serves as unique reference ID for payments. Currently, Odoo sets the Item Trace Number of all payments as a zero-filled sequence According to CPA-005 standards on the Item Trace Number: "The data elements (b), (c) and (d) each must be greater than zero or the TRANSACTION WILL BE REJECTED" (page 36). https://www.payments.ca/sites/default/files/standard005eng.pdf Steps to reproduce: 1. Install the module l10n_ca_payment_cpa005 2. Go into "CA Company" 3. In the configuration for "CA Company", add something to the fields "Short Name used in Canadian EFT" and "Company ID" i.e. "CCC" 4. Set all the fields in the "Canadian EFT/CPA Configuration" section of the bank journal 5. Set the bank record on the bank journal. Set the field "Financial Institution ID Number" field of the "Account Number" record of the bank journal to any numerical sequence 6. Create a bank account on "Azure Interior" and make sure to check the field to trust the bank account that you created (otherwise there will be an error) 7. Create two payments with the vendor of "Azure Interior" using the payment method of "Canadian EFT" 8. Create a batch payment for both payments created 9. Validate the batch payment and the export file should show up in the chatter 10. Note that in the export file, the Item Trace Number for each payment is set to be all zeros, whereas it should be a nonzero identification sequence Solution: Set the Item Trace Number to be the payment's id opw-6323432 Forward-Port-Of: odoo/enterprise#123707 Forward-Port-Of: odoo/enterprise#123633
Customers can now add suggested accessory products from the cart when buying rental items with day-based pricing. This prevents an error caused by rental date formatting, improving checkout reliability for rental sales.
Original PR description
Steps to reproduce: =================== 1. Create a rental product with a day-based rental period (e.g. 1 day) and a non-rental accessory product. 2. Add the rental product to the cart. 3. From the cart page, click "Add to cart" on the suggested accessory. => RPC error: ValueError: unconverted data remains: .999999 Root cause: =========== For rental products priced on a non-hourly recurrence, the cart's rental_return_date is stored as the end of day in the website timezone, i.e. with .999999 microseconds. The suggested-products button renders the rental dates as raw str(datetime) into its data attributes, and the accessory add-to-cart sent them verbatim to /shop/cart/add, where fields.Datetime.to_datetime() cannot parse microseconds. Fix: ==== Round-trip the data-attribute values through deserializeDateTime / serializeDateTime so the controller receives the standard server datetime format without microseconds, like every other renting flow. opw-6372176
This change stops Sendcloud delivery shipments from including tax numbers in customs information by reverting a previous update. It helps ensure customs data sent to the carrier matches the intended requirements and avoids sharing unnecessary tax details.
Original PR description
Revert of c696339. ----- Ticket: opw-6384570
This fix corrects how Belgian CODA bank statement data is read after a related compatibility change. It prevents import errors and ensures the correct statement details are used when processing bank files.
Original PR description
In this commit: https://github.com/odoo/enterprise/commit/54ff6637af96533e7f035eeff84f79336dc4650b we made a fix because thanks to this commit:https://github.com/odoo/enterprise/commit/c66995fda83e19b28a38312af8efdc1601881cf0 where we did a backport of the extension number. The backport adds the extension number to the return of the _parse_bank_statement_file. With that we have 4 args returned. Without the * we would have the "too many value to unpack" error. But when doing that we miss to change the stmt_vals = data to take the last element. Otherwise, we will have a list of two elements. no task id
This fixes an issue where companies using Peru localization could not create a certificate when Chile localization was also installed. The Chile-specific serial number requirement now applies only where appropriate, preventing unnecessary setup errors for other Latin American companies.
Original PR description
With a l10n_pe company and having a l10n_cl company installed: - Try to create a certificate in the settings, there is a missing field error. The template certificate_certificate_view_form have a required subject_serial_number field in l10n_cl but it shouldn't in other latam localization. opw-6274126
Demo social feed comments now use the correct standard demo user data after older demo partner data was removed. This ensures comments in demo mode show the right author image, making demo feeds look consistent and accurate.
Original PR description
Bug === Since ce264a2 , we remove the demo partner in the social_demo module, but we didn't update the code to use the demo data in base. Task-6293738
Point of Sale Avalara tax calculations now use the company/shop location instead of requiring a customer address, making checkout tax handling fit normal in-store sales. This also fixes quantity-based subtotal tax calculation and adds broader tests to help keep the flow reliable.
Original PR description
The module behaves in an unexpected way: - Tax is based on a customer's home address, - To calculate tax a customer must be selected, - Tax is calculated as if shipped from the warehouse selected on…
The module behaves in an unexpected way: - Tax is based on a customer's home address, - To calculate tax a customer must be selected, - Tax is calculated as if shipped from the warehouse selected on pos_warehouse_id This could be useful in very obscure scenarios (B2B sales, traveling salesmen), but for those cases customers can already use our Avatax integration on sale orders. We want this module to be useful for normal B2C POS sales. Taxes they charge are the same regardless of where the customer may live. This commit makes many changes: - Stop requiring a customer to be selected, - Always calculate local sales (from company location to company location) if the Avatax option is enabled on pos.config, - Fix a bug where price_subtotal is not multiplied by quantity, - Removes copy/pasted code from sale.order that serves no purpose, This makes the module useful for companies that don't want to manually figure out what taxes to charge. This could be especially useful for companies with many shops in different locations. A tour test was added to make sure the module keeps working. The test added before [1] was removed because it was redundant and less complete than the one included here. This is deliberately not backported to Odoo 18 [2]. We keep the current behavior there. [1] https://github.com/odoo/odoo/commit/3e94fe90ded58d498f0098cd9ed8679cbe500b8f Closes odoo/enterprise#82779 task-4710463
Accounting report exports now send dates to Excel as actual date values instead of plain text. This makes exported reports easier to sort, filter, format, and reuse without manual cleanup, and also prevents an export crash when date-time values are processed.
Original PR description
Before this commit, columns with figure_type 'date'/'datetime', General Ledger's Date column, but also Partner Ledger, Aged Partner Balance, Bank Reconciliation and Customer Statement. were exported…
Before this commit, columns with figure_type 'date'/'datetime', General Ledger's Date column, but also Partner Ledger, Aged Partner Balance, Bank Reconciliation and Customer Statement. were exported to XLSX as plain text strings instead of real Excel date values. _get_cell_type_value, which decides whether a cell must be written as a date or as text, only recognized a cell as a date when its 'class' contained 'date'. _build_column_dict, used by every report to build its column cells, never set that key, so the check always failed and cells fell back to text, even though figure_type was correctly set to 'date' on them. _build_column_dict now also sets 'class': 'date' on date datetime columns, the same convention already used by hand-built cells in account_followup This in turn revealed a second, so-far dormant issue: once real datetime values started reaching the XLSX writer, _set_xlsx_cell_sizes crashed while estimating the column width, as it unconditionally tried float(value) to shorten long numbers and only guarded against value errors and overflow errors, not the TypeError raised by float() on a datetime object. It now skips that numeric-shortening step for date/datetime values, like it already did for None. opw-6276398
This update adds the Belgian CODA extension module to the translation configuration. It helps ensure the module can be included in the normal translation workflow, with no direct change to day-to-day user behavior.
Original PR description
This commit will add l10n_be_coda_extension_number in the weblate json file. no task id
This fixes details in Hong Kong IRD payroll reports so assessment years are calculated from the correct employee start or leaving dates. It also enforces that an “other” leaving reason includes an explanation, helping submissions meet IRD certification requirements.
Original PR description
As we now have complete support for IRD reports (in master), we started to try to get our system certified by the IRD.
A first submission highlighted a few issues that we are now fixing.
From 19.0:
- In IR56F, the RTN_ASS_YR should be the tax year in which the employee left the company. E.g. after april, the next year.
- In the same report, if the code for the cessation reason is 5 (other), the reason MUST be provided.
From 19.2:
- Same change has to be done when setting RTN_ASS_YR for IR56G
- A same change has to also be done for IR56E, based on the date the employee joined the company.
task-6332150Printing an appraisal form from the action menu now waits briefly so the menu can close before the browser print dialog opens. This prevents the menu from appearing on printed appraisal documents, improving the professionalism and clarity of the output.
Original PR description
When printing the appraisal form from the action (cog) menu, the drop down menu itself was incorrectly showing up in the printed document. This happened because the browser started printing immediately before the menu had time to close. By adding a small delay before triggering the print action, the menu now has time to completely close, so it no longer appears in the final print. task-6369240
This update makes the database authentication module available for translation work, helping improve language coverage for users. It also corrects minor wording mistakes and adjusts an internal error check that users would not encounter directly.
Original PR description
The aim of this commit is to allow the translator to work on this module translation and fix a typo that was made. Task-id: None
This fix prevents an error when users clear the start or end date on a Mexican payroll payslip. The system now checks that dates are present before running salary-limit warning calculations, so payroll users can edit payslip periods without disruption.
Original PR description
Currently, an error occurs when a user removes the payslip dates. **Steps to reproduce:** - Install the `l10n_mx_hr_payroll_account_edi` module with demo data. - Switch to `ZAPATERIA URTADO ÑERI`…
Currently, an error occurs when a user removes the payslip dates. **Steps to reproduce:** - Install the `l10n_mx_hr_payroll_account_edi` module with demo data. - Switch to `ZAPATERIA URTADO ÑERI` company - Go to `Payslips`, create a payslip. - Set an `employee`, and remove either the `start date` or the `end date` from Period.. `TypeError: unsupported operand type(s) for +: 'bool' and 'relativedelta'` After the [recent commit] adding a warning about the employee exceeding the salary limit, when the user removes the dates from the payslip, the compute method attempts to compute the warning from [1], and when it adds relativedelta to date_from, which is False, it raises the error [2]. This commit ensures that the payslip dates are checked first before adding relativedelta to the date and performing the comparison. [recent commit]: https://github.com/odoo/enterprise/commit/6abfa47dafe439f9328d606ef6ac5126ec6eb1f6 [1]- https://github.com/odoo/enterprise/blob/53a7fd4d53ffd510ad42632c69ce9d3a22c59e70/hr_payroll/models/hr_payslip.py#L1446 [2]- https://github.com/odoo/enterprise/blob/53a7fd4d53ffd510ad42632c69ce9d3a22c59e70/l10n_mx_hr_payroll_account_edi/models/hr_payslip.py#L272-L276
Signed recruitment offer certificates now show the applicant's actual email address instead of a placeholder. This prevents confusion when reviewing signature certificates and keeps recruitment records accurate.
Original PR description
similar to https://github.com/odoo/enterprise/pull/120566/changes/b5b6589c9c91980e41d025ae74082af63907debc When generating an offer from the recruitment application and signing it, the applicant's…
similar to https://github.com/odoo/enterprise/pull/120566/changes/b5b6589c9c91980e41d025ae74082af63907debc When generating an offer from the recruitment application and signing it, the applicant's email address is incorrectly displayed. ### **Steps to Reproduce:** 1) Install sign, recruitment, hr_contract_salary 2) Create an new application and add basic detail like name and email as (path and path@test.com) 3) Generate offer and sign with all the required signer. 4) Open the application form view and open the certificate. ### **Observed Behavior:** Email is not set correctly in the generated certificate (appearing as john@example.com). ### **Expected Behavior:** The email of the applicant should be correctly set(e.g as path@test.com) ### **Root Cause:** When the applicant signs the document, their email is explicitly set to `False` at [1]. This is done because the applicant is not linked to any user yet. Later, when generating the certificate, the system attempts to display the user's partner email at [2], which is `False`, causing the default fallback value (`john@example.com`) to be printed. [1]- https://github.com/odoo/enterprise/blob/49226f4109c7d7bb48340949951e70f4245d0e5b/hr_contract_salary/controllers/main.py#L53-L54 [2]- https://github.com/odoo/enterprise/blob/49226f4109c7d7bb48340949951e70f4245d0e5b/sign/report/sign_log_reports.xml#L59 ### **Fix:** Use `signer_email` instead of the partner's email to ensure the correct email is displayed on the certificate every time. **opw-6280170** Forward-Port-Of: odoo/enterprise#123901 Forward-Port-Of: odoo/enterprise#123767
Sendcloud shipping labels now correctly keep dots in address numbers, such as “12.345”, instead of shortening them. This prevents incorrect house number data being sent to Sendcloud and helps ensure delivery labels match the customer address.
Original PR description
Issue ----- Labels have unexpected format when the delivery address has a dot (`.`) in the number. Steps to reproduce ----- - Set up Sendcloud (carrier shouldn't matter) - Enable logs - Create a customer (with valid address, phone and email) - Address must contain a dot, eg Grand Place 12.345 - Deliver a product to the customer - Add sendcloud as delivery method - Go to the logs - Open the "sendcloud request parcels" log > house_number is 12 Cause ----- The `house_number` field is populated using `_get_house_number`, where the regex used to extract the number from the address line does not accept the `.` character. https://github.com/odoo/enterprise/blob/f93882555864a1f0a2a3e3863780096c78923bfa/delivery_sendcloud/models/sendcloud_service.py#L323 ----- Ticket: opw-6295904 Forward-Port-Of: odoo/enterprise#123266
The Documents app now keeps the Actions menu usable when several documents are selected. This prevents users from getting stuck when trying to apply bulk actions, while preserving the correct selected-document count after uploads.
Original PR description
***Issue:*** Since https://github.com/odoo/enterprise/commit/8baaad621a1555680cd77ab514f626137b5b584d the div holding the selection box and the Actions menu carries t-key="targetRecords.length" in…
***Issue:*** Since https://github.com/odoo/enterprise/commit/8baaad621a1555680cd77ab514f626137b5b584d the div holding the selection box and the Actions menu carries t-key="targetRecords.length" in the documents list and kanban views, so every change of the selection count destroys and recreates everything inside it. Ticking a document checkbox updates both the selection and the focused record, and with these two updates the recreation goes wrong: the new ActionMenus component ends up destroyed while its button is still in the page. The dropdown click listeners are removed with the component, so clicking Actions does nothing until the selection changes again. That t-key was added because the selection box shows a stale count after a file upload. The real problem is that SelectionBox caches this.root once in setup. The upload flow reloads the model, which replaces the root record list, and the box keeps counting the selection of the old one. ***Fix:*** Remove the t-key from documents_list_controller.xml and documents_kanban_controller.xml and make DocumentsSelectionBox read the current props.root instead of the value cached by the parent setup. The count follows the new record list after an upload without remounting anything, and the Actions menu is not recreated so its dropdown keeps working. The upload scenario stays covered by the existing multi_view.test.js test, a new test checks that the Actions menu opens with two selected documents. ***Steps to reproduce:*** 1. Open the Documents app 2. Switch to the list view 3. Tick the checkboxes of two documents 4. Click the Actions button next to the "2 selected" box => the Actions dropdown does not open Ticket [link](https://www.odoo.com/odoo/project.task/6365618) opw-6365618 Forward-Port-Of: odoo/enterprise#123575
5 changes
Resolved issues and error corrections
This update resolves an issue where dragging tables in the HTML editor caused layout problems. Now, tables can be seamlessly dropped and pasted, maintaining their original formatting and functionality, ensuring a smoother editing experience.
Original PR description
**Current behavior before PR:** - Dragging and dropping a selected table caused the layout of the dropped table to become broken. **Desired behavior after PR is merged:** - Now, dragging and dropping a selected table now maintains the table's layout, ensuring that the entire table is dropped without any layout issues. task:4138408
This update fixes an issue where pressing 'Enter' within a code block nested in a list would incorrectly create a new list item. Now, 'Enter' will simply add a new line within the existing code block, providing a smoother and more intuitive editing experience for code snippets.
Original PR description
Current behavior before PR: - When the cursor was placed within the text of a code block that was a child of a list, pressing enter create a new list item containing a code block. Desired behavior after PR is merged: - Now, if the cursor is positioned within the text of a code block that was child of a list, pressing enter will insert a new line within the code block instead of creating a new list item. task:4240721
This update addresses a technical issue where a report was failing when analytic plans were not available. The fix ensures the system gracefully handles missing plans, preventing errors and maintaining data accuracy. This resolves a previously reported problem (OPW-6383774, OPW-6383787) and improves report stability.
Original PR description
After this commit 403d9d7, current_plans is being used to get the column name but not always have a analytic plan. To fix this issue we review if is empty or not. OPW-6383774 OPW-6383787 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where the DSO (Days Sales Outstanding) data on the Invoice Dashboard was misaligned. The problem stemmed from a discrepancy in how fiscal years were handled, leading to inaccurate reporting. This change ensures the DSO data accurately reflects invoice performance.
Original PR description
Invoice dashboard data, specifically DSO, was incorrectly aligned due to a mismatch in the fiscal year structure. Task-6049887
This update corrects a crash that occurred when the system attempted to merge partners using UUID-formatted access tokens. The fix ensures the system correctly handles both the older numeric partner ID format and the newer UUID format, preventing errors and improving stability.
Original PR description
The SQL query in _update_foreign_keys was casting access_token to integer unconditionally, but website_visitor.access_token is a Char field that uses two formats: - Legacy: partner_id stored as a numeric string (e.g. '105249') - Current: 32-char UUID hex string (e.g. 'b0dd4bfd041f4b42957357ba7e067dda') The ::int cast raises InvalidTextRepresentation on UUID-format tokens. Fix: guard the cast with a regex so only rows with numeric access_tokens are processed; UUID-format rows are left untouched. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
4 changes
Enhancements to existing features
This update improves the performance and reliability of our website's image galleries by upgrading the Owl library to the latest version (2.8.4). Specifically, it fixes a bug that caused lost coalesced renders and adds support for running Owl with Node.js, enhancing our development flexibility.
Original PR description
- [FIX] runtime: don't lose coalesced renders - [IMP] loadable with nodejs See https://github.com/odoo/owl/commits/owl-2.x/ for more details 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#275568
Resolved issues and error corrections
This update addresses a potential issue where product combinations could get stuck in an infinite loop, causing Odoo instances to freeze. The change sets a maximum iteration limit to prevent this, ensuring smoother operation and preventing prolonged downtime. This was triggered during a recent database migration and, while a rare occurrence, could have significant impact.
Original PR description
Sometimes, products get stuck for a long time while getting variant combinations in production. Sets a maximum iteration limit to prevent an infinite loop. The issue occurred on a production database migrated from Odoo 11.0 to 17.0. Even if it is a corner case, it can block Odoo workers in an infinite loop and bring the entire instance down
This update fixes a mapping issue with Worldline's Cofidis payment method. Previously, the system used an outdated payment product ID, leading to incorrect payment processing. Now, the mapping is updated to the latest Worldline documentation, ensuring accurate and reliable payment transactions.
Original PR description
opw-6368979 Description of the issue/feature this PR addresses: Update the Worldline Cofidis payment method mapping to match the latest payment product ID defined in the Worldline documentation. Current behavior before PR: The Cofidis payment method was mapped to the outdated payment product ID (3012), causing payment requests to use an incorrect mapping. Desired behavior after PR is merged: The Cofidis payment method is mapped to the correct payment product ID (5129) as per the latest Worldline documentation, ensuring payment requests use the correct mapping.
This update ensures that the default placeholder in the Klipy search feature displays "Search KLIPY", as required by Klipy's attribution guidelines. This change maintains proper compliance and enhances the user experience when using Klipy within Odoo. It's a minor fix to improve consistency.
Original PR description
Klipy requires attribution with "Search KLIPY" as the default placeholder [1]. This commit complies these guidelines. [1]: https://docs.klipy.com/attribution