Daily updates from Odoo
Navigate
Branch
Thursday, April 30, 2026
265 changes
17 changes
Enhancements to existing features
This update limits the duration of automatically recurring events to 15 years by default, preventing excessive event creation and ensuring predictable scheduling. Administrators can adjust this limit for specific events if needed, maintaining event organization and reducing potential system strain.
Original PR description
`forever` recurrent events could currently be created for 720 years into the future, leading to excessive and unnecessary event generation. This change limits the creation of forver recurrent events to a fixed horizon of 15 years (by default) in the future, ensuring predictable behavior and preventing unbounded recurrence. The maximum horizon can be adjusted through the system parameter `calendar.max_recurrence_years` for events that require a longer recurrence window. Task-5714633 Forward-Port-Of: odoo/odoo#261808 Forward-Port-Of: odoo/odoo#247929
Resolved issues and error corrections
This update strengthens the security of Xendit payments by requiring a valid access token linked to the specific transaction being processed. Previously, payments could be executed without this verification, creating a potential risk. Now, payments are restricted to the correct transaction, improving data integrity and security.
Original PR description
**Description of the issue/feature this PR addresses:** The `/payment/xendit/payment` endpoint did not enforce validation of an access token tied to the transaction when processing direct payment requests. **Current behavior before PR:** The endpoint accepted public requests using only the transaction reference, allowing payment execution without verifying that the request was linked to the intended transaction. **Desired behavior after PR is merged:** The endpoint now requires a valid access_token associated with the transaction (reference) before processing. This ensures that payment execution is restricted to the correct transaction. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261912 Forward-Port-Of: odoo/odoo#260258
This update resolves an error preventing users from accessing the Spain VAT Books report. The issue stemmed from an outdated reference in a template, which has now been corrected. This ensures all users can generate the required VAT reports.
Original PR description
**Steps to reproduce:** - Install the `l10n_es_reports` and `accountant` modules. - Switch to an ES Company. - Navigate to Accounting > Reporting > Spain > `VAT Books`. **Error:** `Element '<xpath…
**Steps to reproduce:** - Install the `l10n_es_reports` and `accountant` modules. - Switch to an ES Company. - Navigate to Accounting > Reporting > Spain > `VAT Books`. **Error:** `Element '<xpath expr="//button[@t-if='this.props.line.chatter and !this.ui.isSmall']" position="replace"/>' cannot be located in element tree` **Root Cause:** After commit [1], the condition `this.ui.isSmall` was removed from the template `account_reports.AccountReportLineNameCustomizable` at [2]. However, the inherited template `l10n_es_reports.VatBooksLineName` was not updated accordingly and still references the old condition, which leads to the error. **Fix:** This commit prevents errors and ensures that users can open the `VAT Books` report by applying a fix similar to [2]. [1]: https://github.com/odoo-dev/enterprise/commit/fd0afa474600586e8703ec377f962c8d7d94307a [2]: https://github.com/odoo/enterprise/blob/7362f1c5be7f496bdab660ed8fad37a6dd283616/account_reports/static/src/components/account_report/line_name/line_name.xml#L81 opw-6169697 opw-6170173 Forward-Port-Of: odoo/enterprise#115412
This update ensures the IRN (Invoice Reference Number) generated during E-Invoicing is correctly saved and displayed on the invoice itself, both in the PDF and the invoice form. Previously, the IRN was only present in the PDF but not on the invoice record, now it's consistently saved for easier tracking and reporting.
Original PR description
**Steps to reproduce:** * Install module *Indian - GSTR with E-invoice (l10n_in_edi_gstr)*. * Configure *Indian integration* with required credentials (E-Invoicing, E-Way bill, etc.). * Save the…
**Steps to reproduce:** * Install module *Indian - GSTR with E-invoice (l10n_in_edi_gstr)*. * Configure *Indian integration* with required credentials (E-Invoicing, E-Way bill, etc.). * Save the settings. * Create a *customer invoice*. * Post the invoice. * Send the invoice through *E-Invoicing (EDI)*. * Open the generated *Invoice PDF* and the *form view*. **Observed behavior:** * The *IRN number* is correctly present in the *Invoice PDF*. * However, it is *not saved/displayed* in the invoice form view. **Cause:** * The invoice flow did not store the *IRN number* on the invoice after receiving the EDI response, even though the value was available. **Fix:** * Inherit *_l10n_in_edi_send_invoice*. * Add a condition after the invoice is sent and the JSON response is received. * When the *IRN number* is present in the response, set it on the *l10n_in_irn_number* field of the invoice (in lower case). opw-6097923 Forward-Port-Of: odoo/enterprise#115522 Forward-Port-Of: odoo/enterprise#114350
This update corrects a bug that prevented users from successfully booking appointments with flexible hour slots. The issue stemmed from a rounding error in how appointment URLs were generated, leading to a 404 error. The fix ensures accurate slot durations are used, allowing for seamless appointment booking.
Original PR description
Steps to reproduce: 1. Install `appointment` 2. Create an appointment type with the followings 3. Schedule type flexible and a slot of 20 min. 4. Share this appointment and try to book appointment…
Steps to reproduce: 1. Install `appointment` 2. Create an appointment type with the followings 3. Schedule type flexible and a slot of 20 min. 4. Share this appointment and try to book appointment for 20 min. Issue: - 404 Error occurs after selectiong the slot Cause: - In 19.0, commit https://github.com/odoo/enterprise/commit/9bae0e13e7bf5e0db25a60fc2683bc51eccb4447 started using slot.duration when building the booking URL for flexible slots. However, slot.duration is rounded to 2 decimals, so a 20-minute slot is serialized as 0.33 instead of its exact value. During validation, the end datetime is recomputed from this rounded duration, which no longer matches the original slot boundaries. This mismatch causes the slot to be considered invalid and the controller raises NotFound. Solution: - Compute the slot duration directly from slot_start_dt_tz and slot_end_dt_tz when building the URL, preserving the full precision. opw-5924312 Forward-Port-Of: odoo/enterprise#108870
This update fixes an issue where the POS system was loading all employees, regardless of their employee type, leading to performance slowdowns. Now, the POS session only loads employees based on the configured employee type (basic, advanced, or minimal), optimizing performance and resource usage. This change ensures a smoother and faster POS experience.
Original PR description
Before this commit, when some employee was assigned to advanced or minimal employee, all of the employees were loaded in the POS session, because there was no basic employee assigned to the POS config. opw-5898068 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260805 Forward-Port-Of: odoo/odoo#247043
This update resolves an issue where the POS system was loading all employees, regardless of their role, leading to performance slowdowns. The fix ensures that only the necessary employee types are loaded during a POS session, improving system responsiveness and efficiency. This change addresses a technical issue impacting POS performance.
Original PR description
Before this commit, when some employee was assigned to advanced or minimal employee, all of the employees were loaded in the POS session, because there was no basic employee assigned to the POS config. opw-5898068 Forward-Port-Of: odoo/enterprise#115109
This update corrects a bug in the ESG module's calculations for emission factors. The previous system incorrectly handled unit and currency conversions, leading to inaccurate emission values. This fix ensures that emission calculations are now precise and reliable.
Original PR description
Issue: ---------------------------------------- The conversions using Emission factors are done in the wrong way. Steps to reproduce: ---------------------------------------- - Install `esg` module - Create an Emission Factor from ton to kg of 1000 - Create a new Emission using the new factor, set the unit as kg - Notice the conversion is wrong Cause: ---------------------------------------- The two uom are inverted when calling `_compute_quantity()`. Same occured for the currencies. opw-6152413 Forward-Port-Of: odoo/enterprise#115575 Forward-Port-Of: odoo/enterprise#115246
This update fixes an issue where the leave balance report was incorrectly calculating employee leave accruals and balances, particularly when leaves were taken over multiple periods. The fix ensures accurate reporting by addressing timezone discrepancies and improving the calculation of overlapping leave allocations. This improves the reliability of leave tracking data.
Original PR description
__ISSUE__: - FIFO balance miscalculation for non-overlapping allocations. cumulative_allocated_days was partitioned globally by (employee, leave_type), but taken_per_allocation scoped leaves to each…
__ISSUE__:
- FIFO balance miscalculation for non-overlapping allocations. cumulative_allocated_days was partitioned globally by (employee, leave_type), but taken_per_allocation scoped leaves to each allocation's date range. This caused the FIFO formula to silently absorb leaves from one period into another's allocation capacity.
ex:
Alloc A (20 days) 2025, taken leaves 15 days
Alloc B (20 days) 2026, taken leaves 5 days
report: 2025: (15 taken), (5 left)
2026: (7 taken), (20 left)
- Left" rows shifted by one year in non-UTC timezones. Allocation date_from/date_to (Date fields) were cast to timestamp as midnight UTC. In negative-UTC /positive-UTC timezones midnight UTC of Dec 31 renders as the prev/next day.
__FIX__:
- detect overlap groups using a running MAX(date_to) and partition the cumulative sums within each overlap group. This way non-overlapping allocations are treated as independent, while overlapping or open-ended allocations still share FIFO within their group.
- offset allocation dates by 12 hours so no timezone can shift them across a day boundary.
- opw-5169606
- opw-5352114
Forward-Port-Of: odoo/odoo#259083
Forward-Port-Of: odoo/odoo#257873This update resolves an issue where power buttons were incorrectly displayed and overlapping other menu items in the HTML editor, particularly on smaller screens. The fix adjusts the editor's width to determine when to hide the buttons, ensuring a cleaner and more usable experience for users.
Original PR description
Problem: Power buttons are shown regardless of the editor field's actual rendered width, causing them to overlap other menus when the field is small. Solution: Instead of relying solely on the global…
Problem: Power buttons are shown regardless of the editor field's actual rendered width, causing them to overlap other menus when the field is small. Solution: Instead of relying solely on the global `ui.isSmall` (mobile detection), check the editor field's own width and hide power buttons whenever it falls below the overlap threshold. Before: <img width="576" height="301" alt="image" src="https://github.com/user-attachments/assets/dcebed55-5c80-4fe5-8d33-c320549cf347" /> After: <img width="542" height="336" alt="image" src="https://github.com/user-attachments/assets/34a233bb-9958-43ac-adb9-04702a2e403d" /> Steps to reproduce: - Change languange (French to have a long placeholder). - Settings > Customer Invoices > Default Terms & Conditions. - Check "Add a Note". - Resize the screen to smaller size. - Observe the power buttons overlap with the translate button. task-6117734 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261881 Forward-Port-Of: odoo/odoo#259094
This update resolves an issue where the IoT box pairing dialog could freeze indefinitely. Additionally, it corrects a localization problem where the 'Connecting' placeholder wasn't properly translated, ensuring a smoother user experience for all languages. This improves the reliability of the IoT integration.
Original PR description
This commit fixes two small issues with IoT pairing: 1. When pairing an IoT box, even after the DB has discovered the IoT box and added it as a record, the dialog will keep waiting forever. If you close the dialog manually the IoT box appears as expected. 2. If using a language other than English, the placeholder 'Connecting' name will not be replaced when the IoT finishes pairing. The IoT box can still be used as normal however. Forward-Port-Of: odoo/enterprise#115627
This update corrects a reporting issue within the GSTR-3B report for Indian companies using the '18% IGST (IMP-Service)' tax. The previous configuration resulted in the tax not being accurately reflected in the report. This fix ensures correct reporting of service taxes, aligning with Indian tax regulations.
Original PR description
**Steps to reproduce:** - Install l10n_in_reports - Switch to an Indian company (e.g. IN Company) - Create a bill with a Service product and "18% IGST (IMP-Service)" tax - Confirm the bill - Go to "Accounting / Reporting / India / GSTR-3B" **Issue:** In "4. (A) (2) Import of services" section of the report, the bill that has been created is not taken into account. **Cause:** The "18% IGST (IMP-Service)" tax has a distribution of: * 100% of the tax in "100570" account with "IGST" tax tag * -100% of the tax in same account with "IGST" tax tag Therefore, both distribution lines with the tax tag cancel themselves. opw-6116356 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260631
This update resolves a bug that prevented users from scheduling rental tours correctly. Previously, attempts to set times in the past would cause scheduling errors. The fix ensures tours always use valid, future dates and times, improving the reliability of the rental booking process.
Original PR description
Since 605c8b47d52854e36c7cb822ccb2d40de44c4c3c, rourly rental products default to a rental period starting at the next hour of the current day. Tours override the time of the rental period, but not the date. If the tours tries to set a time which is in the past, the datepicker will discard the time, breaking the tour. Scenario: Running the tour between 11am-11:59am breaks test_website_sale_renting_ui: - Product page shows default times: today 12pm (start) to 1pm (end) - Tour tries to set start time to 8am - Datepicker rejects 8am (it's before the current time 11am-11:59am) and keeps 12pm - Tour then sets end time to 12pm, resulting in equal start and end times - Equal times are invalid, cart addition fails, tour breaks This commit, extracts the existing utility function into a shared helper that returns a guaranteed future date (next Monday + offset), ensuring tours always set valid times regardless of when they run. runbot-243459
This update resolves an issue where multi-company invoices were experiencing errors due to incorrect tax calculations. The change ensures tax information is handled securely, preventing crashes when products from different companies are involved. This improves the reliability of invoicing for businesses using Odoo's multi-company functionality.
Original PR description
Description of the issue this commit addresses: In multi-company setups, invoice line tax recomputation could read product or account taxes in user context and trigger an AccessError on account.tax when products carry taxes from another company. Desired behavior after this commit is merged: This patch hardens account.move.line tax recomputation paths by reading tax M2M values in sudo and returning filtered results in normal env, so compute logic no longer crashes on cross-company tax records. Ticket [link](https://www.odoo.com/odoo/project.task/6036638) opw-6036638 Forward-Port-Of: odoo/odoo#260948
This update corrects a technical issue within the Odoo Enterprise system's onboarding tour for overtime rules. Previously, the tour incorrectly targeted a UI element, leading to a confusing user experience. This fix ensures the tour accurately guides users through the correct process for setting up overtime.
Original PR description
The tour previously matched the input field underneath the popup and interacted with the wrong element, the fix scope the selector to the modal. task-6172067 Forward-Port-Of: odoo/enterprise#115458
This update resolves an issue where backorder returns weren't properly associated with the original delivery. The change ensures that when a backorder is created from a return, the return's ID is correctly set, allowing for accurate tracking and reporting of returned items within the delivery context. This improves inventory accuracy and reporting.
Original PR description
### Steps to reproduce: - Create, confirm and validate a delivery for 2 units of a product A - Click Return > Return All - Validate the return for 1 unit and backorder #### > The backorder does not belong to the return list of the delivery ### Cause of the issue: Backorder pickings are created by copying the picking to backorder: https://github.com/odoo/odoo/blob/9ad995ff6b59a6a2fdfbbd6cf385fe27568dd3ea/addons/stock/models/stock_picking.py#L1580-L1593 https://github.com/odoo/odoo/blob/9ad995ff6b59a6a2fdfbbd6cf385fe27568dd3ea/addons/stock/models/stock_picking.py#L1571-L1578 However, the `return_id` is a `copy=False` field that is not manully set during this copy process: https://github.com/odoo/odoo/blob/9ad995ff6b59a6a2fdfbbd6cf385fe27568dd3ea/addons/stock/models/stock_picking.py#L558 opw-6111544 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261831 Forward-Port-Of: odoo/odoo#259804
This update resolves an issue where users could unintentionally bypass tax group restrictions when changing Argentinian fiscal packages. The system now explicitly checks for a 'force_delete' flag, ensuring that tax group deletions are handled correctly and restoring the previous behavior. This prevents data inconsistencies and maintains the integrity of Argentinian tax reporting.
Original PR description
Commit 947e4dc9de3a replaced MODULE_UNINSTALL_FLAG with an explicit 'force_delete' context flag, and as the commit message warns, callees that relied on the previous flag must now detect 'force_delete' on their own. There is no automatic bypass anymore. **STEP TO REPRODUCE** 1.- Install l10n_ar 2-. Select one argentinian regime (fiscal package) & save 3-. Try to change package **FIX** Detect 'force_delete' in check_uninstall_required and return early, restoring 19.0 behavior. Manual deletions of the tax group are still blocked. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261561
21 changes
Enhancements to existing features
This update enhances the bank reconciliation process by displaying the analytic distribution of each reconciliation line. This provides users with clearer insights into where funds are being allocated, improving accuracy and reducing potential errors. The changes were adapted from existing bank reconciliation components.
Original PR description
For automated reco models, we didn't take the amount into account. That means that some lines could have a suggestion of reco model that makes no sense. This commit will allow to show the analytic distribution of a line in the line to reconcile so that it's clear for the user. (Most of the code is taken from the analytic distribution widget and adapted) Also make the popover works on hover task-5733382 Forward-Port-Of: odoo/enterprise#106118
Resolved issues and error corrections
This update fixes a critical issue where gift cards and e-wallets could be reused after being refunded, leading to potential misuse. It now prevents refunds and ensures order lines are created correctly when products are linked to multiple loyalty programs, improving program accuracy and preventing data inconsistencies.
Original PR description
Previously, it was possible to refund a gift card or e-wallet after creation. However, the associated code remained usable, allowing the gift card or e-wallet to be reused, which is not the expected behavior. To address this, refunds for gift cards and e-wallets are now prevented. Additionally, when a product is part of the trigger products for multiple gift card or e-wallet programs, it was not possible to create separate order lines for the same product with different programs selected. The second line was merged into the first. A condition has been added to prevent merging when different programs are selected. --- Task: https://www.odoo.com/odoo/project/1737/tasks/6052281 Forward-Port-Of: odoo/odoo#261647 Forward-Port-Of: odoo/odoo#256896
This update strengthens the security of Xendit payments by requiring a valid access token linked to the specific transaction. Previously, payments could be processed without this verification, creating a potential risk. Now, payments are restricted to the correct transaction, improving security and preventing unauthorized payments.
Original PR description
**Description of the issue/feature this PR addresses:** The `/payment/xendit/payment` endpoint did not enforce validation of an access token tied to the transaction when processing direct payment requests. **Current behavior before PR:** The endpoint accepted public requests using only the transaction reference, allowing payment execution without verifying that the request was linked to the intended transaction. **Desired behavior after PR is merged:** The endpoint now requires a valid access_token associated with the transaction (reference) before processing. This ensures that payment execution is restricted to the correct transaction. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261912 Forward-Port-Of: odoo/odoo#260258
This update ensures the IRN (Invoice Reference Number) generated during E-Invoicing EDI submission is correctly saved and displayed in both the Invoice PDF and the invoice form within Odoo. Previously, the IRN was only present in the PDF but not on the invoice itself, now it's consistently available.
Original PR description
**Steps to reproduce:** * Install module *Indian - GSTR with E-invoice (l10n_in_edi_gstr)*. * Configure *Indian integration* with required credentials (E-Invoicing, E-Way bill, etc.). * Save the…
**Steps to reproduce:** * Install module *Indian - GSTR with E-invoice (l10n_in_edi_gstr)*. * Configure *Indian integration* with required credentials (E-Invoicing, E-Way bill, etc.). * Save the settings. * Create a *customer invoice*. * Post the invoice. * Send the invoice through *E-Invoicing (EDI)*. * Open the generated *Invoice PDF* and the *form view*. **Observed behavior:** * The *IRN number* is correctly present in the *Invoice PDF*. * However, it is *not saved/displayed* in the invoice form view. **Cause:** * The invoice flow did not store the *IRN number* on the invoice after receiving the EDI response, even though the value was available. **Fix:** * Inherit *_l10n_in_edi_send_invoice*. * Add a condition after the invoice is sent and the JSON response is received. * When the *IRN number* is present in the response, set it on the *l10n_in_irn_number* field of the invoice (in lower case). opw-6097923 Forward-Port-Of: odoo/enterprise#115522 Forward-Port-Of: odoo/enterprise#114350
This update resolves an issue where the 'Remove Format' function would get stuck in an infinite loop when used with icons and background colors in the To-do app. The fix ensures that icons are correctly processed during format removal, preventing the loop and restoring normal functionality.
Original PR description
Steps to reproduce: =================== 1. Open the To-do app and pick any task. 2. In the description add text and an icon with a bg color. `(you can add this: <i class="fa rounded rounded-circle…
Steps to reproduce: =================== 1. Open the To-do app and pick any task. 2. In the description add text and an icon with a bg color. `(you can add this: <i class="fa rounded rounded-circle fa-user bg-o-color-1 fa-4x" contenteditable="false"></i>)` 3. Select all and click "Remove format". Result: -> Traceback due to an infinite loop. Cause: ====== Remove format calls `removeAllColor()`, which loops forever at: https://github.com/odoo/odoo/blob/626bde21a25366d0bb29662bae2057c247a1638e/addons/html_editor/static/src/main/font/color_plugin.js#L194-L194 Why: _applyColor doesn't remove the icon's background class, so hasAnySelectedNodeColor keeps returning true and the removal loop never terminates. This happens because `font` is already the `<i>` element with the `fa` class, using `querySelectorAll` on it won't include the element itself, so the icon is never checked or updated. https://github.com/odoo/odoo/blob/6cdc6f55886ea48e90f9023a6c6142bf072745b9/addons/html_editor/static/src/main/font/color_plugin.js#L290 Solution: ========= Check if the font itself has the fa class before doing the `querySelectorAll`, and include it in the nodes to check for color. Test Impact: ============ Before this fix, a `<span>` containing an icon was wrapped in a `<font>` when applying color, treating the icon as a normal span (without size) instead of applying the color directly. https://github.com/odoo/odoo/blob/8792c2d38eb0aadac8d778d83fd76f270404ecd5/addons/html_editor/static/src/main/font/color_plugin.js#L397 opw-5928627 Forward-Port-Of: odoo/odoo#261405 Forward-Port-Of: odoo/odoo#248449
This update resolves an issue where exporting VSME reports would fail if the base year was not a valid 4-digit number. The fix adds validation to ensure only correct years are used, preventing errors and ensuring report generation continues smoothly. This improves data reliability for VSME reporting.
Original PR description
Currently, an error occurs when exporting VSME reports if the base year is not a valid 4-digit year. **Steps to Reproduce:** 1. Install the `esg_csrd` module with demo data. 2. Create new "**VSME Reports**" with `Base Year = 1`. 3. Now, click on "**Print**". **Error:** `ValueError - Invalid isoformat string: '1-01-01'` **Cause:** The base year is directly used to build a date in [1], resulting in `datetime.date(1, 1, 1)`. In [2], this is formatted to **"1-01-01"** and used in a domain search, which raises a ValueError due to an invalid ISO date format. **Fix:** - Adds a **constraint on base year** to ensure only valid years (1000–9999) are allowed for new VSME Report records. - Adds a **helper validation method** to verify base year before performing computations on existing records. sentry-7419431039 Forward-Port-Of: odoo/enterprise#114453
This update corrects a bug that prevented users from successfully booking appointments with flexible hour slots in the 19.2 release. The issue stemmed from a rounding error in how appointment URLs were generated, leading to a 404 error. The fix ensures accurate slot durations are used, allowing for seamless appointment booking.
Original PR description
Steps to reproduce: 1. Install `appointment` 2. Create an appointment type with the followings 3. Schedule type flexible and a slot of 20 min. 4. Share this appointment and try to book appointment…
Steps to reproduce: 1. Install `appointment` 2. Create an appointment type with the followings 3. Schedule type flexible and a slot of 20 min. 4. Share this appointment and try to book appointment for 20 min. Issue: - 404 Error occurs after selectiong the slot Cause: - In 19.0, commit https://github.com/odoo/enterprise/commit/9bae0e13e7bf5e0db25a60fc2683bc51eccb4447 started using slot.duration when building the booking URL for flexible slots. However, slot.duration is rounded to 2 decimals, so a 20-minute slot is serialized as 0.33 instead of its exact value. During validation, the end datetime is recomputed from this rounded duration, which no longer matches the original slot boundaries. This mismatch causes the slot to be considered invalid and the controller raises NotFound. Solution: - Compute the slot duration directly from slot_start_dt_tz and slot_end_dt_tz when building the URL, preserving the full precision. opw-5924312 Forward-Port-Of: odoo/enterprise#108870
This update restricts the future duration of recurring calendar events to 15 years by default, preventing excessive event creation and ensuring predictable scheduling. Administrators can adjust this limit for specific events needing longer recurrence periods. This improves system stability and resource management.
Original PR description
`forever` recurrent events could currently be created for 720 years into the future, leading to excessive and unnecessary event generation. This change limits the creation of forver recurrent events to a fixed horizon of 15 years (by default) in the future, ensuring predictable behavior and preventing unbounded recurrence. The maximum horizon can be adjusted through the system parameter `calendar.max_recurrence_years` for events that require a longer recurrence window. Task-5714633 Forward-Port-Of: odoo/odoo#261808 Forward-Port-Of: odoo/odoo#247929
This update fixes an issue where the POS system was loading all employees, regardless of their role, leading to performance slowdowns. The change now ensures that only basic employees are loaded, improving the speed and efficiency of the POS experience. This resolves a previous bug related to employee configuration settings.
Original PR description
Before this commit, when some employee was assigned to advanced or minimal employee, all of the employees were loaded in the POS session, because there was no basic employee assigned to the POS config. opw-5898068 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260805 Forward-Port-Of: odoo/odoo#247043
This update resolves an issue where the POS system was loading all employees, regardless of configuration. Previously, the absence of a basic employee assignment caused this. Now, the system only loads employees based on the POS configuration, improving performance and reducing unnecessary data loading.
Original PR description
Before this commit, when some employee was assigned to advanced or minimal employee, all of the employees were loaded in the POS session, because there was no basic employee assigned to the POS config. opw-5898068 Forward-Port-Of: odoo/enterprise#115109
This update clarifies how WHT reporting is handled in the accounting system. Previously, the system incorrectly mixed WHT closing entries with VAT closing entries, leading to potential reporting errors. This fix removes a specific return type, ensuring accurate and separate reporting of WHT transactions.
Original PR description
WHT does not require a closing entry. The current return type is causing VAT closing entry to mix with WHT closing entry or vice versa. task-6157814 Forward-Port-Of: odoo/enterprise#115576
This update resolves an issue where power buttons were incorrectly displayed and overlapping other menu items within the HTML editor, particularly on smaller screens. The fix adjusts the editor's width detection to ensure buttons are hidden when they cause overlap, improving the user experience and visual consistency.
Original PR description
Problem: Power buttons are shown regardless of the editor field's actual rendered width, causing them to overlap other menus when the field is small. Solution: Instead of relying solely on the global…
Problem: Power buttons are shown regardless of the editor field's actual rendered width, causing them to overlap other menus when the field is small. Solution: Instead of relying solely on the global `ui.isSmall` (mobile detection), check the editor field's own width and hide power buttons whenever it falls below the overlap threshold. Before: <img width="576" height="301" alt="image" src="https://github.com/user-attachments/assets/dcebed55-5c80-4fe5-8d33-c320549cf347" /> After: <img width="542" height="336" alt="image" src="https://github.com/user-attachments/assets/34a233bb-9958-43ac-adb9-04702a2e403d" /> Steps to reproduce: - Change languange (French to have a long placeholder). - Settings > Customer Invoices > Default Terms & Conditions. - Check "Add a Note". - Resize the screen to smaller size. - Observe the power buttons overlap with the translate button. task-6117734 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261881 Forward-Port-Of: odoo/odoo#259094
This update resolves an issue where the IoT box pairing dialog could freeze indefinitely. Additionally, it corrects a localization problem where the 'Connecting' placeholder wasn't updating correctly for non-English users. These changes ensure a smoother and more reliable experience when adding IoT boxes to the system.
Original PR description
This commit fixes two small issues with IoT pairing: 1. When pairing an IoT box, even after the DB has discovered the IoT box and added it as a record, the dialog will keep waiting forever. If you close the dialog manually the IoT box appears as expected. 2. If using a language other than English, the placeholder 'Connecting' name will not be replaced when the IoT finishes pairing. The IoT box can still be used as normal however. Forward-Port-Of: odoo/enterprise#115627
This update corrects a reporting issue within the GSTR-3B report for Indian companies using the '18% IGST (IMP-Service)' tax. Previously, the report incorrectly excluded bills with this tax. The fix adjusts the tax distribution to ensure accurate reporting of IGST liabilities, resolving a discrepancy in import of services.
Original PR description
**Steps to reproduce:** - Install l10n_in_reports - Switch to an Indian company (e.g. IN Company) - Create a bill with a Service product and "18% IGST (IMP-Service)" tax - Confirm the bill - Go to "Accounting / Reporting / India / GSTR-3B" **Issue:** In "4. (A) (2) Import of services" section of the report, the bill that has been created is not taken into account. **Cause:** The "18% IGST (IMP-Service)" tax has a distribution of: * 100% of the tax in "100570" account with "IGST" tax tag * -100% of the tax in same account with "IGST" tax tag Therefore, both distribution lines with the tax tag cancel themselves. opw-6116356 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260631
This update resolves an issue where multi-company invoice calculations were failing due to incorrect tax access permissions. The change ensures tax calculations are performed securely, regardless of the company context, preventing errors and improving invoice processing reliability.
Original PR description
Description of the issue this commit addresses: In multi-company setups, invoice line tax recomputation could read product or account taxes in user context and trigger an AccessError on account.tax when products carry taxes from another company. Desired behavior after this commit is merged: This patch hardens account.move.line tax recomputation paths by reading tax M2M values in sudo and returning filtered results in normal env, so compute logic no longer crashes on cross-company tax records. Ticket [link](https://www.odoo.com/odoo/project.task/6036638) opw-6036638 Forward-Port-Of: odoo/odoo#260948
This update corrects a formatting issue in the e-waybill document date field. Previously, both date and time were displayed, which is now standardized to show only the date. This ensures consistent reporting and compliance with required document formats.
Original PR description
The `document_date` field in e-waybill form view previously included both date and time, which is not as per the expected format. This fix ensures that only the date is shown, hiding the time component. Forward-Port-Of: odoo/odoo#261253 Forward-Port-Of: odoo/odoo#259656
This update corrects a bug that prevented customers from being found using their email addresses. The system was incorrectly searching for emails in the phone field instead. This change ensures accurate customer retrieval based on email, improving data accuracy and usability.
Original PR description
The email-based lookup was mistakenly checking the phone field (`phone = email`) instead of the email field. Because of this, customers could not be correctly found using their email address. This change fixes the domain to properly match on the email field. Forward-Port-Of: odoo/odoo#260567
This update fixes an issue where backorders created from returns weren't properly associated with the original return. Previously, the system didn't correctly set a link between the backorder and the return, leading to reporting discrepancies. This change ensures that backorders generated from returns are accurately tracked within the return process.
Original PR description
### Steps to reproduce: - Create, confirm and validate a delivery for 2 units of a product A - Click Return > Return All - Validate the return for 1 unit and backorder #### > The backorder does not belong to the return list of the delivery ### Cause of the issue: Backorder pickings are created by copying the picking to backorder: https://github.com/odoo/odoo/blob/9ad995ff6b59a6a2fdfbbd6cf385fe27568dd3ea/addons/stock/models/stock_picking.py#L1580-L1593 https://github.com/odoo/odoo/blob/9ad995ff6b59a6a2fdfbbd6cf385fe27568dd3ea/addons/stock/models/stock_picking.py#L1571-L1578 However, the `return_id` is a `copy=False` field that is not manully set during this copy process: https://github.com/odoo/odoo/blob/9ad995ff6b59a6a2fdfbbd6cf385fe27568dd3ea/addons/stock/models/stock_picking.py#L558 opw-6111544 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261831 Forward-Port-Of: odoo/odoo#259804
This update resolves an issue preventing the MPESA payment method from correctly processing transactions initiated by Safaricom. It disables CSRF checks on callback endpoints and ensures URLs use HTTPS, addressing a common error related to invalid URLs. Additionally, the code now incorporates a 'till number' for transactions, improving data accuracy.
Original PR description
1. The `MPESA` payment method needs a callback url where it does a `POST` request with the transaction details. Since the call comes from safaricom, CSRF will block those requests. This commit will…
1. The `MPESA` payment method needs a callback url where it does a `POST` request with the transaction details. Since the call comes from safaricom, CSRF will block those requests. This commit will disable CSRF checks on the callback endpoints which are expected to be called from an external service 2. Sometimes the `web.base.url` parameter is automatically set to http. But safaricom expects https for all the urls. So we need to ensure that the urls we send on `lipa_na_mpesa_register_urls` use https, otherwise the registration fails with an `invalid url` error. Additionally, I added the error message in case of error 4. In addition to the business short code we also need a till number for transactions. Since this is stable, I've added the till number as an extension of the business shortcode field and then parse it before usage. On master there is a new PR which will properly separate the fields Task-[6045833](https://www.odoo.com/odoo/project/1737/tasks/6045833) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254993
This update resolves an issue where unreconciling bank statements with batch payments would unexpectedly revert invoices to draft due to approval checks triggered by third-party modules. The fix allows for the necessary repost to occur even when approvals are pending, preventing users from needing to manually re-enter data. This ensures smoother reconciliation processes.
Original PR description
When unreconciling a batch payment from a bank statement line, delete_reconciled_line() resets the linked invoice to draft to recompute its amount_residual, then re-posts it. If a third-party module…
When unreconciling a batch payment from a bank statement line, delete_reconciled_line() resets the linked invoice to draft to recompute its amount_residual, then re-posts it. If a third-party module (e.g. Studio Approvals) silently rejects action_post for the current user, the invoice stays in draft and the user has to redo the work manually. This internal repost is not a business action, the move was already approved when initially posted, so it can run as sudo to bypass approval checks. Steps to reproduce: 1. Add a Studio Approval rule on account.move.action_post with an approver other than the current user 2. As a user without that approval right, post a vendor bill and register a payment 3. Add the payment to a batch payment 4. Reconcile a bank statement line with the batch payment 5. With the user without approval rights, try to unreconcile the bank statement line (delete_reconciled_line) - Expected: the bill stays Posted. - Actual (before fix): the bill silently rolls back to Draft because action_post is rejected by the approval hook. opw-6121448 Forward-Port-Of: odoo/enterprise#115341 Forward-Port-Of: odoo/enterprise#115241
This update resolves a technical issue where an incorrect import statement was present in the core Point of Sale (POS) system. This fix ensures the system functions correctly and prevents potential errors related to data processing within the POS module. The change is a routine maintenance update.
Original PR description
This PR fixes the wrong import in adam_scale_driver.py opw-6173563 Forward-Port-Of: odoo/enterprise#115625
19 changes
Enhancements to existing features
This update adapts the XLSX export reports to align with new Indonesian tax regulations (Act 2025). Previously, reports relied on specific tax sections, but now they utilize report line names and tax tags for accurate reporting, ensuring compliance with the latest requirements.
Original PR description
In this commit, the XLSX export and report warning are adapted to support the newly introduced TDS/TCS reports as per Act 2025. Previously, the XLSX reports depended on TDS/TCS sections. However, with Act 2025, certain taxes no longer have associated sections. This dependency has been removed, and report generation now relies on report line names and tax tags instead. task-6124431 Forward-Port-Of: odoo/enterprise#113916
Resolved issues and error corrections
This update fixes a performance issue where updating a product's lot or serial number in a picking could trigger slow requests due to fetching all stock quantities. The change ensures that the system respects the specified limit when retrieving quantities, resulting in significantly faster update times. This improves the overall responsiveness of the barcode picking process.
Original PR description
## Problem: During an `onchange` call, if a field is defined in the `fields_spec` with a `limit` attribute, the `fetch` method doesn't respect it, and will fetch all records satisfying the domain. In certain circumstances, this leads to slow requests. ## Solution: Enforce the `limit` when fetching if it is present. ## Steps to reproduce: - Have a product with many quant records 1. Open a picking for this product in Barcode 2. Change the lot/serial The frontend will send an `onchange` request that includes `product_stock_quant_ids` in the `fields_spec` (with default `limit` 40). Odoo will fetch all quants for this product regardless of the limit, and the request will take a while to resolve. ## Benchmark: <table> <thead> <tr> <th># of quants</th> <th>Before</th> <th>After</th> </tr> </thead> <tbody> <tr> <td>17193</td> <td>~9s</td> <td>~400ms</td> </tr> </tbody> </table> opw-6041705 Forward-Port-Of: odoo/odoo#259983
This update strengthens the security of Xendit payments by requiring a valid access token linked to the specific transaction. Previously, payments could be processed without this verification, creating a potential risk. Now, payments are restricted to the correct transaction, improving security and preventing unauthorized payments.
Original PR description
**Description of the issue/feature this PR addresses:** The `/payment/xendit/payment` endpoint did not enforce validation of an access token tied to the transaction when processing direct payment requests. **Current behavior before PR:** The endpoint accepted public requests using only the transaction reference, allowing payment execution without verifying that the request was linked to the intended transaction. **Desired behavior after PR is merged:** The endpoint now requires a valid access_token associated with the transaction (reference) before processing. This ensures that payment execution is restricted to the correct transaction. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261912 Forward-Port-Of: odoo/odoo#260258
This update fixes an issue where the IRN (Invoice Reference Number) generated during E-Invoicing EDI submission wasn't correctly saved or displayed on the invoice itself. The fix ensures the IRN number is now present in both the generated PDF invoice and the invoice form view, streamlining invoice tracking for users.
Original PR description
**Steps to reproduce:** * Install module *Indian - GSTR with E-invoice (l10n_in_edi_gstr)*. * Configure *Indian integration* with required credentials (E-Invoicing, E-Way bill, etc.). * Save the…
**Steps to reproduce:** * Install module *Indian - GSTR with E-invoice (l10n_in_edi_gstr)*. * Configure *Indian integration* with required credentials (E-Invoicing, E-Way bill, etc.). * Save the settings. * Create a *customer invoice*. * Post the invoice. * Send the invoice through *E-Invoicing (EDI)*. * Open the generated *Invoice PDF* and the *form view*. **Observed behavior:** * The *IRN number* is correctly present in the *Invoice PDF*. * However, it is *not saved/displayed* in the invoice form view. **Cause:** * The invoice flow did not store the *IRN number* on the invoice after receiving the EDI response, even though the value was available. **Fix:** * Inherit *_l10n_in_edi_send_invoice*. * Add a condition after the invoice is sent and the JSON response is received. * When the *IRN number* is present in the response, set it on the *l10n_in_irn_number* field of the invoice (in lower case). opw-6097923 Forward-Port-Of: odoo/enterprise#115522 Forward-Port-Of: odoo/enterprise#114350
This update resolves an error that occurred when exporting VSME reports if the base year was invalid. The fix ensures that only valid 4-digit years are used, preventing a data processing error and ensuring accurate report generation. This improves the reliability of VSME reporting.
Original PR description
Currently, an error occurs when exporting VSME reports if the base year is not a valid 4-digit year. **Steps to Reproduce:** 1. Install the `esg_csrd` module with demo data. 2. Create new "**VSME Reports**" with `Base Year = 1`. 3. Now, click on "**Print**". **Error:** `ValueError - Invalid isoformat string: '1-01-01'` **Cause:** The base year is directly used to build a date in [1], resulting in `datetime.date(1, 1, 1)`. In [2], this is formatted to **"1-01-01"** and used in a domain search, which raises a ValueError due to an invalid ISO date format. **Fix:** - Adds a **constraint on base year** to ensure only valid years (1000–9999) are allowed for new VSME Report records. - Adds a **helper validation method** to verify base year before performing computations on existing records. sentry-7419431039 Forward-Port-Of: odoo/enterprise#114453
This update corrects a technical issue preventing users from successfully booking appointments with flexible hour slots. The problem stemmed from an incorrect calculation of appointment durations, leading to a 404 error. The fix ensures accurate slot durations are used when building booking URLs, allowing for seamless appointment scheduling.
Original PR description
Steps to reproduce: 1. Install `appointment` 2. Create an appointment type with the followings 3. Schedule type flexible and a slot of 20 min. 4. Share this appointment and try to book appointment…
Steps to reproduce: 1. Install `appointment` 2. Create an appointment type with the followings 3. Schedule type flexible and a slot of 20 min. 4. Share this appointment and try to book appointment for 20 min. Issue: - 404 Error occurs after selectiong the slot Cause: - In 19.0, commit https://github.com/odoo/enterprise/commit/9bae0e13e7bf5e0db25a60fc2683bc51eccb4447 started using slot.duration when building the booking URL for flexible slots. However, slot.duration is rounded to 2 decimals, so a 20-minute slot is serialized as 0.33 instead of its exact value. During validation, the end datetime is recomputed from this rounded duration, which no longer matches the original slot boundaries. This mismatch causes the slot to be considered invalid and the controller raises NotFound. Solution: - Compute the slot duration directly from slot_start_dt_tz and slot_end_dt_tz when building the URL, preserving the full precision. opw-5924312 Forward-Port-Of: odoo/enterprise#108870
This update resolves an issue where power buttons were incorrectly displayed and overlapping other menu items within the HTML editor, particularly on smaller screens. The fix adjusts the editor's width detection to ensure buttons are hidden when they cause overlap, improving the user experience and visual consistency.
Original PR description
Problem: Power buttons are shown regardless of the editor field's actual rendered width, causing them to overlap other menus when the field is small. Solution: Instead of relying solely on the global…
Problem: Power buttons are shown regardless of the editor field's actual rendered width, causing them to overlap other menus when the field is small. Solution: Instead of relying solely on the global `ui.isSmall` (mobile detection), check the editor field's own width and hide power buttons whenever it falls below the overlap threshold. Before: <img width="576" height="301" alt="image" src="https://github.com/user-attachments/assets/dcebed55-5c80-4fe5-8d33-c320549cf347" /> After: <img width="542" height="336" alt="image" src="https://github.com/user-attachments/assets/34a233bb-9958-43ac-adb9-04702a2e403d" /> Steps to reproduce: - Change languange (French to have a long placeholder). - Settings > Customer Invoices > Default Terms & Conditions. - Check "Add a Note". - Resize the screen to smaller size. - Observe the power buttons overlap with the translate button. task-6117734 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261881 Forward-Port-Of: odoo/odoo#259094
This update corrects a reporting issue where the '18% IGST (IMP-Service)' tax wasn't accurately reflected in the GSTR-3B report. The fix adjusts how tax distributions are handled, ensuring the correct service tax amount is imported. This ensures accurate tax reporting for Indian businesses.
Original PR description
**Steps to reproduce:** - Install l10n_in_reports - Switch to an Indian company (e.g. IN Company) - Create a bill with a Service product and "18% IGST (IMP-Service)" tax - Confirm the bill - Go to "Accounting / Reporting / India / GSTR-3B" **Issue:** In "4. (A) (2) Import of services" section of the report, the bill that has been created is not taken into account. **Cause:** The "18% IGST (IMP-Service)" tax has a distribution of: * 100% of the tax in "100570" account with "IGST" tax tag * -100% of the tax in same account with "IGST" tax tag Therefore, both distribution lines with the tax tag cancel themselves. opw-6116356 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260631
This update resolves an issue where multi-company invoices were experiencing errors due to incorrect tax calculations. The change ensures that tax data is handled securely, preventing access errors when products from different companies are involved. This improves invoice processing reliability for businesses using Odoo's multi-company feature.
Original PR description
Description of the issue this commit addresses: In multi-company setups, invoice line tax recomputation could read product or account taxes in user context and trigger an AccessError on account.tax when products carry taxes from another company. Desired behavior after this commit is merged: This patch hardens account.move.line tax recomputation paths by reading tax M2M values in sudo and returning filtered results in normal env, so compute logic no longer crashes on cross-company tax records. Ticket [link](https://www.odoo.com/odoo/project.task/6036638) opw-6036638 Forward-Port-Of: odoo/odoo#260948
This update corrects a formatting issue in the e-waybill document date field. Previously, both date and time were displayed, which is not the required format. This change ensures consistent and accurate date reporting for e-waybills.
Original PR description
The `document_date` field in e-waybill form view previously included both date and time, which is not as per the expected format. This fix ensures that only the date is shown, hiding the time component. Forward-Port-Of: odoo/odoo#261253 Forward-Port-Of: odoo/odoo#259656
This update corrects a bug where the system was incorrectly searching for customers using phone numbers instead of email addresses. The change ensures customers can now be accurately found and retrieved using their email, improving customer data access. This resolves a previous issue preventing correct customer searches.
Original PR description
The email-based lookup was mistakenly checking the phone field (`phone = email`) instead of the email field. Because of this, customers could not be correctly found using their email address. This change fixes the domain to properly match on the email field. Forward-Port-Of: odoo/odoo#260567
This update resolves an issue where backorders created from returns weren't properly associated with the original return. The fix ensures the `return_id` is correctly set during the backorder creation process, allowing for accurate tracking and reporting of returned items. This improves the reliability of our inventory management system.
Original PR description
### Steps to reproduce: - Create, confirm and validate a delivery for 2 units of a product A - Click Return > Return All - Validate the return for 1 unit and backorder #### > The backorder does not belong to the return list of the delivery ### Cause of the issue: Backorder pickings are created by copying the picking to backorder: https://github.com/odoo/odoo/blob/9ad995ff6b59a6a2fdfbbd6cf385fe27568dd3ea/addons/stock/models/stock_picking.py#L1580-L1593 https://github.com/odoo/odoo/blob/9ad995ff6b59a6a2fdfbbd6cf385fe27568dd3ea/addons/stock/models/stock_picking.py#L1571-L1578 However, the `return_id` is a `copy=False` field that is not manully set during this copy process: https://github.com/odoo/odoo/blob/9ad995ff6b59a6a2fdfbbd6cf385fe27568dd3ea/addons/stock/models/stock_picking.py#L558 opw-6111544 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261831 Forward-Port-Of: odoo/odoo#259804
This update resolves an issue preventing the MPESA payment method from correctly processing transactions initiated by Safaricom. Specifically, it disables CSRF checks on callback endpoints and ensures URLs use HTTPS, addressing a common error related to invalid URLs. Additionally, the code now incorporates the till number for transactions, streamlining the process.
Original PR description
1. The `MPESA` payment method needs a callback url where it does a `POST` request with the transaction details. Since the call comes from safaricom, CSRF will block those requests. This commit will…
1. The `MPESA` payment method needs a callback url where it does a `POST` request with the transaction details. Since the call comes from safaricom, CSRF will block those requests. This commit will disable CSRF checks on the callback endpoints which are expected to be called from an external service 2. Sometimes the `web.base.url` parameter is automatically set to http. But safaricom expects https for all the urls. So we need to ensure that the urls we send on `lipa_na_mpesa_register_urls` use https, otherwise the registration fails with an `invalid url` error. Additionally, I added the error message in case of error 4. In addition to the business short code we also need a till number for transactions. Since this is stable, I've added the till number as an extension of the business shortcode field and then parse it before usage. On master there is a new PR which will properly separate the fields Task-[6045833](https://www.odoo.com/odoo/project/1737/tasks/6045833) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254993
This update resolves a technical issue where the payroll amount calculation wasn't consistently triggered when a default value was set for a specific field. The change ensures the calculation is always performed correctly, regardless of the initial default value selected, improving payroll accuracy.
Original PR description
The compute is not triggered when a default value is assigned to a field. So all property inputs default to 'fix' for amount_select. This removes the default parameter from the field and adds the default value to the compute method. task-6126332
This update fixes an issue where the Datev CSV export incorrectly calculated tax amounts for vendor bills with multiple tax repartition lines. The fix ensures accurate tax reporting by correctly summing the tax amounts when multiple lines are associated with a single tax, improving the reliability of financial data exports.
Original PR description
With l10n_de_reports: - Configure a foreign currency with an exchange rate. - Configure a tax with multiple repartition lines. - Create a vendor bill in this foreign currency with this tax. - In the general ledger export the datev csv. In the datev csv the rate is wrong. In the method _l10n_de_datev_get_csv, we build a tax_amount dict. However when one tax has multiple lines, the amount is replaced and not added. opw-6010097 Forward-Port-Of: odoo/enterprise#115535 Forward-Port-Of: odoo/enterprise#110453
This update resolves an issue where incorrect Nemhandel identifiers were generated when Danish company VAT numbers with the 'DK' prefix were entered. The change removes the 'DK' prefix from CVR numbers, ensuring accurate identifier generation and a better experience for Danish businesses using Odoo.
Original PR description
Before this PR: - When a user enters a full VAT number with the 'DK' prefix in the company registry, the Nemhandel identifier becomes incorrect and results in a cryptic error being returned to the client. After this PR: - The prefix is removed if the CVR contains the 'DK' country code, to ensure the correctness of the Nemhandel identifier. task-5449059 Forward-Port-Of: odoo/odoo#261856 Forward-Port-Of: odoo/odoo#261719
This update fixes an issue where test tags containing brackets or backslashes weren't parsed correctly, preventing certain tests from running. The changes ensure that complex tag structures, including nested brackets and escaped characters, are now handled properly, improving test reliability. This resolves a technical detail that ensures consistent test execution.
Original PR description
When using test tags for js tests, some tests are not parsed correctly when containing brackets `[ ]` This is because the tag selector use them to set parameters bounds as in…
When using test tags for js tests, some tests are not parsed correctly when containing brackets `[ ]` This is because the tag selector use them to set parameters bounds as in `.test_method[test_param]` The previous implementation using a regex could generate invalid test tags when the params contains comma, and brackets This commits fixes this two ways: Nested brackets will work, meaning that something like `.test_method[test, witch brackets[]]` will be correctly parsed as a tag `.test_method` with a parameter `test, witch brackets[]`since the brakets are balanced. Before, it was parsed as twho tags, `.test_method[test` and ` witch brackets[]]` the second one being considered invalid and spamming logs with errors Brackets and backslashes can be escaped with a backslash, meaning that something like `.test_method[test, with brackets], and backslash\]` can be escaped as `.test_method[test, with brackets\], and backslash\\]` Note that the parser will make it's best effort to parse non escaped strings, so a \ not followed by and escaped character will remain there in order to make potential copy paste easier. For the previous example `.test_method[test, with brackets\], and backslash\` will work the same way. So in practice, we only really need to escape \ when followed by another backslash or a bracket, and we need to escape brackets when they are not balanced. Comma in hoot tests are also a problem since they are used to separate parameters, this can easily be tested by only splitting on `,@` since all hoot test should start with a @ and parameters of test_unit_* tests should be a list of hoot tests. A followup pr will introduce the params to the canonical tag, and escape it as needed Forward-Port-Of: odoo/odoo#261896 Forward-Port-Of: odoo/odoo#261516
This update corrects a previous issue where all employees could see each other's overtime hours. The root cause was a setting in the system's calculations that granted excessive access. The fix removes this setting and adds new tests to ensure this problem doesn't reoccur.
Original PR description
- Step to reproduce: everyone can see everyones overtimes. - Cause: total_overtime compute method is using `compute_sudo=True`. - Solution: removing compute_sudo and adding tests Task: 6125021 Forward-Port-Of: odoo/odoo#261496
This update resolves an issue where certain expense accounts were incorrectly included in default reporting filters. Specifically, accounts related to exchange differences and early payment discounts are now properly categorized as 'Other Expenses'. This ensures more accurate financial reporting and analysis.
Original PR description
[FIX] account: Default account filter include Other Expense In "Defalut Accounts" setting, adding `expense_other` in the search domain for the following accounts: - Exchange difference entries > Loss - Early payment discounts > Early Discount Gain - Early payment discounts > Early Discount Loss task-6116375 Forward-Port-Of: odoo/odoo#259583
2 changes
Resolved issues and error corrections
This update ensures that barcode validations in the stock picking app correctly check if a destination has been scanned before processing. Previously, the system didn't verify destination scanning, even when enabled. This change ensures accurate validation and prevents issues with incomplete picking processes.
Original PR description
### Steps to reproduce: - In the settings: Enable "Storage Locations" - Inventory > Configuration > Warehouse Management > Operation Types - On receipts, in the Barcode App tab enable: "Force a…
### Steps to reproduce: - In the settings: Enable "Storage Locations" - Inventory > Configuration > Warehouse Management > Operation Types - On receipts, in the Barcode App tab enable: "Force a destination on all products" - Open the barcode app, create a new receipt - Scan a product > Validate #### > You are not blocked by the fact that you did not scan any destination even just to validate the default one ### Cause of the issue: The `barcode_validation_after_dest_location` operation type setting is not used at any point in the barcode app. ### Note: Line in the barcode app are always created a with a `location_dest_id`: https://github.com/odoo/enterprise/blob/a220fc61d9076decdb987421df9330a1c2c20546/stock_barcode/static/src/models/barcode_picking_model.js#L1310-L1322 In particular, even if the setting says: Force a destination on all products. It should rather be interpreted as force a destination scan before validation. Note that a destination scan will not necessarily update a single line but rather all concerned lines at once: https://github.com/odoo/enterprise/blob/a220fc61d9076decdb987421df9330a1c2c20546/stock_barcode/static/src/models/barcode_picking_model.js#L1558-L1576 It is therefore a valid call to check if a location dest was scanned to determine if the a destination was set on each product before validation of the picking, even if it is just to confirm the default destination. ### Note 2: We modify the `_get_barcode_config` to only provide a `barcode_validation_after_dest_location` if locations re enabled otherwise users enabling the option without the ability to scan locations would be soft lock and unable to validate their picking. That same logic already being applied to the `restrict_scan_dest_location` config parameter: https://github.com/odoo/enterprise/blob/6afe02e3e836df2822d7cae8aebbd5bdde6b34cc/stock_barcode/models/stock_picking_type.py#L109 opw-6110690 Forward-Port-Of: odoo/enterprise#115534 Forward-Port-Of: odoo/enterprise#114429
This update resolves an issue where the Mod347 BOE export incorrectly included Spanish companies with invoices below the threshold. The fix removes an unnecessary search that was adding these companies to the export, ensuring only relevant partners are included based on the primary reporting requirements. This improves the accuracy of the BOE export for Spanish businesses.
Original PR description
Fix a bug in mod347 BOE export. Steps to reproduce: 1- Create an invoice with a spain Company, with an amount lower than 3 005,06€ 2- Add a Type for mod347 3- Create a cash payment 4- Export the mod347 BOE The partner will appear in the BOE with all line at 0. But this partner shouldn't be in the export. This is due because of a search on account.partial.reconcile, which add partners to the export if a cash payment is found in the period. But this search is not usefully as there is no legal indication that these partners should be in the export in this case, as the partners should only be returned by the main queries. Backport of PR #84317 opw-5960226 Forward-Port-Of: odoo/enterprise#114672 Forward-Port-Of: odoo/enterprise#110947
8 changes
Resolved issues and error corrections
This update resolves an issue where invoices rejected by the Italian tax system (SdI) remained marked as 'sent' in Odoo, preventing users from resubmitting them. The change automatically clears the 'is_move_sent' flag when an invoice is rejected, allowing for correct resubmission and streamlining the invoicing process. This ensures Italian businesses can quickly correct errors and avoid delays.
Original PR description
When an invoice is rejected by the SdI or by a PA partner, the move remained flagged as sent, preventing the user from resending it after fixing the underlying issue. Override write() on account.move to clear is_move_sent whenever l10n_it_edi_state transitions to 'rejected' or 'rejected_by_pa_partner', so the invoice can be re-submitted. task-4490454 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#260591
This update fixes an issue where test tags containing brackets or backslashes weren't parsed correctly, preventing certain tests from running. The changes ensure that complex tag parameters, including nested brackets and escaped characters, are now handled accurately, improving test reliability.
Original PR description
When using test tags for js tests, some tests are not parsed correctly when containing brackets `[ ]` This is because the tag selector use them to set parameters bounds as in…
When using test tags for js tests, some tests are not parsed correctly when containing brackets `[ ]` This is because the tag selector use them to set parameters bounds as in `.test_method[test_param]` The previous implementation using a regex could generate invalid test tags when the params contains comma, and brackets This commits fixes this two ways: Nested brackets will work, meaning that something like `.test_method[test, witch brackets[]]` will be correctly parsed as a tag `.test_method` with a parameter `test, witch brackets[]`since the brakets are balanced. Before, it was parsed as twho tags, `.test_method[test` and ` witch brackets[]]` the second one being considered invalid and spamming logs with errors Brackets and backslashes can be escaped with a backslash, meaning that something like `.test_method[test, with brackets], and backslash\]` can be escaped as `.test_method[test, with brackets\], and backslash\\]` Note that the parser will make it's best effort to parse non escaped strings, so a \ not followed by and escaped character will remain there in order to make potential copy paste easier. For the previous example `.test_method[test, with brackets\], and backslash\` will work the same way. So in practice, we only really need to escape \ when followed by another backslash or a bracket, and we need to escape brackets when they are not balanced. Comma in hoot tests are also a problem since they are used to separate parameters, this can easily be tested by only splitting on `,@` since all hoot test should start with a @ and parameters of test_unit_* tests should be a list of hoot tests. A followup pr will introduce the params to the canonical tag, and escape it as needed Forward-Port-Of: odoo/odoo#261896 Forward-Port-Of: odoo/odoo#261516
This update fixes a formatting issue in the e-waybill document date field. Previously, both date and time were displayed, which is now corrected to show only the date. This ensures consistency and accuracy in e-waybill documentation.
Original PR description
The `document_date` field in e-waybill form view previously included both date and time, which is not as per the expected format. This fix ensures that only the date is shown, hiding the time component. Forward-Port-Of: odoo/odoo#261253 Forward-Port-Of: odoo/odoo#259656
This update resolves an issue where customers couldn't be found using their email addresses. The system was incorrectly searching for emails in the phone field. This change ensures accurate customer retrieval based on email, improving data accuracy and customer identification.
Original PR description
The email-based lookup was mistakenly checking the phone field (`phone = email`) instead of the email field. Because of this, customers could not be correctly found using their email address. This change fixes the domain to properly match on the email field. Forward-Port-Of: odoo/odoo#260567
This update corrects a technical issue that could cause problems with voice message tests. The fix ensures that asynchronous operations related to voice playback complete before resolving promises, preventing race conditions. This improves the stability and reliability of voice messaging functionality.
Original PR description
Before this commit, voice message tests don't wait until the voice player is drawn before resolving the corresponding promise. This may lead to race conditions. This commit fixes the issue by properly `await`ing the completion of the asynchronous code before resolving the promise. Related runbot error: https://runbot.odoo.com/odoo/error/163783 Forward-Port-Of: odoo/odoo#261910 Forward-Port-Of: odoo/odoo#261795
This update resolves a technical issue that could cause instability in voice message testing. The change ensures that asynchronous operations complete before promises are resolved, preventing race conditions and improving the reliability of our voice messaging functionality. This enhances the overall stability of the Odoo Enterprise platform.
Original PR description
Before this commit, voice message tests don't wait until the voice player is drawn before resolving the corresponding promise. This may lead to race conditions. This commit fixes the issue by properly `await`ing the completion of the asynchronous code before resolving the promise. Related runbot error: https://runbot.odoo.com/odoo/error/242411 Community: https://github.com/odoo/odoo/pull/261910 Forward-Port-Of: odoo/enterprise#115587
This update resolves an issue where Spanish invoices with amounts below a certain threshold were incorrectly appearing in the Mod347 BOE export. The fix eliminates a redundant search process, ensuring that only relevant partners are included based on the primary data requirements. This improves the accuracy of the BOE export for Spanish businesses.
Original PR description
Fix a bug in mod347 BOE export. Steps to reproduce: 1- Create an invoice with a spain Company, with an amount lower than 3 005,06€ 2- Add a Type for mod347 3- Create a cash payment 4- Export the mod347 BOE The partner will appear in the BOE with all line at 0. But this partner shouldn't be in the export. This is due because of a search on account.partial.reconcile, which add partners to the export if a cash payment is found in the period. But this search is not usefully as there is no legal indication that these partners should be in the export in this case, as the partners should only be returned by the main queries. Backport of PR #84317 opw-5960226 Forward-Port-Of: odoo/enterprise#114672 Forward-Port-Of: odoo/enterprise#110947
This update prevents unnecessary state resets for tasks that have been marked as done or canceled. Previously, changing a task's project would reset its state, even after completion. This change ensures tasks remain in their final state, streamlining workflow and reducing potential confusion.
Original PR description
Before this commit, when the project of a task is changed, even if the state of that task is done or cancelled, the state is reset (except if the task is blocked by another one). This behavior is not expected for a task done/cancelled, we should not reconsider that task since it has been done/cancelled and so there is no reason to re-consider it once the project changed. This commit makes sure the state of the task is not reset when the project changed only if the state is a closed state or Waiting state. task-5361864 Forward-Port-Of: odoo/odoo#261648 Forward-Port-Of: odoo/odoo#252752
2 changes
New functionality added to Odoo
This update prepares Odoo for a new Belgian tax regulation. Starting May 1st, a dedicated 'Tax Provision Account' (411800) is required for VAT periodic returns, replacing the previous account. This change ensures compliance with updated Belgian accounting standards.
Original PR description
Starting May 1st, in Belgium the VAT provision account will replace the current account for periodic returns - Adding the new bank account - Adding a new account 'Tax Provision Account' 411800 Community PR: odoo/odoo#255272 Task [link](https://www.odoo.com/odoo/project.task/6044017) task-6044017 Forward-Port-Of: odoo/enterprise#111599
Resolved issues and error corrections
This update resolves an issue where Spanish cash payments weren't correctly appearing in the Mod347 BOE export for invoices under €3,005.06. The fix prevents unnecessary partners from being included in the export by refining the search criteria, ensuring only relevant partners are generated. This improves the accuracy of the BOE reports for Spanish businesses.
Original PR description
Fix a bug in mod347 BOE export. Steps to reproduce: 1- Create an invoice with a spain Company, with an amount lower than 3 005,06€ 2- Add a Type for mod347 3- Create a cash payment 4- Export the mod347 BOE The partner will appear in the BOE with all line at 0. But this partner shouldn't be in the export. This is due because of a search on account.partial.reconcile, which add partners to the export if a cash payment is found in the period. But this search is not usefully as there is no legal indication that these partners should be in the export in this case, as the partners should only be returned by the main queries. Backport of PR #84317 opw-5960226 Forward-Port-Of: odoo/enterprise#114672 Forward-Port-Of: odoo/enterprise#110947
28 changes
New functionality added to Odoo
This update adds integration with Chainway's RFID scanner technology for improved stock management. This allows for faster and more accurate tracking of inventory items, reducing manual data entry and potential errors. The change enhances operational efficiency within the stock module.
Original PR description
- Integration with Chainway RFID scanner task-5162284
Enhancements to existing features
This update simplifies the asset depreciation views in Odoo, making them easier to use. Redundant information has been removed, and the search functionality has been streamlined to focus on key depreciation settings. A default 'Active' filter has been added for clarity.
Original PR description
Simplify the asset depreciation views by removing redundant information and improving usability. The method column is removed from the assets list since it is already included in the depreciation model name. The depreciation model list is cleaned up to show only the model by default, while filters for method, period, and number of depreciations remain available in the search view. A default Active filter is also added to display only active records. task-6128781 Forward-Port-Of: odoo/enterprise#115665 Forward-Port-Of: odoo/enterprise#114419
This update enhances the bank reconciliation process by displaying the analytic distribution of each reconciliation line. This provides users with clearer insight into where funds are allocated, simplifying the reconciliation process. The changes were largely adapted from existing bank reconciliation components.
Original PR description
For automated reco models, we didn't take the amount into account. That means that some lines could have a suggestion of reco model that makes no sense. This commit will allow to show the analytic distribution of a line in the line to reconcile so that it's clear for the user. (Most of the code is taken from the analytic distribution widget and adapted) Also make the popover works on hover task-5733382 Forward-Port-Of: odoo/enterprise#115553 Forward-Port-Of: odoo/enterprise#106118
This update adds a new record, `ai.session`, to track AI chat sessions launched through the website builder. Previously, tracking was unreliable due to manual user input. Now, the system can automatically identify AI sessions based on a unique identifier, enabling features like blocking website iframes during AI processing.
Original PR description
__Before this commit__ The `ai.session` record linked to a `discuss.channel` is not accessible from the frontend. This is a problem for the website builder AI because in some cases we need to know if…
__Before this commit__ The `ai.session` record linked to a `discuss.channel` is not accessible from the frontend. This is a problem for the website builder AI because in some cases we need to know if an AI chat session was launched from the website builder sidebar. For instance, to implement custom behaviors such as blocking the website page iframe while the AI is thinking. As a workaround, we currently check if the channel agent external identifier corresponds to the website builder AI, however this might be edited by the user, which would break the flow. __After this commit__ The inverse field `ai_session_ids` is added to `discuss.channel`. In practice, there might only be a maximum of one `ai.session` linked to a channel, but we keep it plural as a convention for `One2many` fields. Only the `ai.composer` and the `interface_key` linked to the session are put in the store at the moment, but fields can now be easily added if needed. We can now check for the `interface_key` in the frontend to know from which part of the code an AI session was launched. Those models have also been added to the Hoot mock server. The `action_launch_ai_chat` method is added to the `ai.agent` mock model and returns the session and the composer. task-5411100 Forward-Port-Of: odoo/enterprise#114472
This update moves a collection of tests designed to run after the Odoo Enterprise installation. These tests ensure the core functionality is working correctly following the setup process. This improves the stability and reliability of the Enterprise version.
Original PR description
Enterprise counter-part. https://github.com/odoo/odoo/pull/262056
This update removes outdated 'magic buttons' embedded within standard email templates. Instead, these buttons are now added after the email has been processed, streamlining the user experience and ensuring consistent functionality across all email communications. This change improves the reliability of email actions triggered by standard templates.
Original PR description
Before this commit: There were magic buttons that were part of the body of some standard email templates. After this commit: Remove all magic buttons that are part of the body of All standard email templates and add them after the mail is processed Task-3186268
This update adjusts how European leaves are calculated within the payroll system. Now, European leaves are treated as an advance on double holiday pay, ensuring they are taxed in the same manner. This change aligns with European regulations and provides accurate payroll calculations for employees on European leave.
Original PR description
European leaves must be considered as an advance on double holiday. Following that, it should be taxed the same way as double holiday. task-6127284
This update enhances the autofill feature in Odoo's spreadsheet tools, specifically for pivot and list views. Previously, these autofills were limited, but now they correctly handle formulas containing multiple pivot/list functions, ensuring more accurate data population. This improves the usability and reliability of data analysis within the spreadsheet.
Original PR description
This commit makes the pivot/list autofill work when the formula contains pivot/list functions that are not the only function of the formula. The list autofill would override everything, and the pivot autofill would not do anything. We will now autofill the pivot/list function normally and re-use the rest of the formula as is. Task: [6113901](https://www.odoo.com/web#id=6113901&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form)
This update streamlines product variant handling across multiple Odoo modules, improving the user experience and reducing complexity. Key changes include removing redundant features and aligning data structures for a more consistent and efficient workflow. This simplifies product management and improves overall system performance.
Original PR description
* = [account_intrastat,approvals, documents_product, helpdesk_sale_timesheet,hr_expense_stripe,l10n_ke_edi_oscu, l10n_ke_edi_oscu_stock,l10n_pe_edi_stock,mrp_plm, pos_pricer, quality_control,…
* = [account_intrastat,approvals, documents_product, helpdesk_sale_timesheet,hr_expense_stripe,l10n_ke_edi_oscu, l10n_ke_edi_oscu_stock,l10n_pe_edi_stock,mrp_plm, pos_pricer, quality_control, sale_subscription] - Drop all view inheritances targeting the removed product_variant_easy_edit_view - Remove `Product Variants` menus from Approvals and Quality Control -added account_avatax inside the Accounting tab group - Move pos_pricer Pricer group to after the Short Description group in the Sales page remove on_sale_price and pricer_tags_pricelist_id fields from the variant form - Remove product_product_view_list_at_date list view - Remove mrp_plm ECO button from variant form - Update sale_subscription variant field to many2many_tags_color_dot widget - Simplify UI extensions by removing redundant variant-only fields and customizations - Clean obsolete view logic and tests relying on direct variant editing This aligns product variant handling across modules, and ensures a consistent user experience. See Also: Community PR:https://github.com/odoo/odoo/pull/244185 Upgrade PR:https://github.com/odoo/upgrade/pull/9276 task-5207510
Resolved issues and error corrections
This update resolves a bug where rental tour scheduling was failing due to invalid time selections. The fix ensures tours always use a valid future date, preventing errors when attempting to book tours at times before the current day. This improves the reliability of the rental booking process.
Original PR description
Since 605c8b47d52854e36c7cb822ccb2d40de44c4c3c, rourly rental products default to a rental period starting at the next hour of the current day. Tours override the time of the rental period, but not…
Since 605c8b47d52854e36c7cb822ccb2d40de44c4c3c, rourly rental products default to a rental period starting at the next hour of the current day. Tours override the time of the rental period, but not the date. If the tours tries to set a time which is in the past, the datepicker will discard the time, breaking the tour. Scenario: Running the tour between 11am-11:59am breaks test_website_sale_renting_ui: - Product page shows default times: today 12pm (start) to 1pm (end) - Tour tries to set start time to 8am - Datepicker rejects 8am (it's before the current time 11am-11:59am) and keeps 12pm - Tour then sets end time to 12pm, resulting in equal start and end times - Equal times are invalid, cart addition fails, tour breaks This commit, extracts the existing utility function into a shared helper that returns a guaranteed future date (next Monday + offset), ensuring tours always set valid times regardless of when they run. runbot-243459 Forward-Port-Of: odoo/enterprise#115687
This update addresses minor typographical errors and inconsistencies in the French reporting module (l10n_fr_reports). The changes ensure accurate and professional wording within the reports, improving clarity and user experience. This is a routine maintenance fix.
Original PR description
Fixes typos and ensures wording consistency No task ID Forward-Port-Of: odoo/enterprise#115595
This update resolves an issue where the XML files generated for the Hong Kong payroll system were not using the correct encoding format, preventing proper processing by the IRD platform. The fix includes adding a required file header and ensuring the correct encoding is used, ensuring accurate data transmission.
Original PR description
Following recent tests, we noticed that the encoding used when exporting our XML files doesn't follow the required format. We noticed two issues during testing: - The IRD platform expects the file to have BOM included. - The encoding in the header must be capitalized. We solve this in this commit by prepending the BOM bytes to the xml bytes; and making sure to capitalize the URF-8 in the header. task-6150470 --- Note: There will be a lot to do during forward ports, as these have changed quite a bit. (XML support for the other file types, and a proper testing file, at least) Forward-Port-Of: odoo/enterprise#115582 Forward-Port-Of: odoo/enterprise#115227
This update resolves an error preventing users from accessing the Spain VAT Books report. The issue stemmed from an outdated reference in a template, which was corrected to ensure proper functionality. This ensures users can accurately generate and review their VAT reports.
Original PR description
**Steps to reproduce:** - Install the `l10n_es_reports` and `accountant` modules. - Switch to an ES Company. - Navigate to Accounting > Reporting > Spain > `VAT Books`. **Error:** `Element '<xpath…
**Steps to reproduce:** - Install the `l10n_es_reports` and `accountant` modules. - Switch to an ES Company. - Navigate to Accounting > Reporting > Spain > `VAT Books`. **Error:** `Element '<xpath expr="//button[@t-if='this.props.line.chatter and !this.ui.isSmall']" position="replace"/>' cannot be located in element tree` **Root Cause:** After commit [1], the condition `this.ui.isSmall` was removed from the template `account_reports.AccountReportLineNameCustomizable` at [2]. However, the inherited template `l10n_es_reports.VatBooksLineName` was not updated accordingly and still references the old condition, which leads to the error. **Fix:** This commit prevents errors and ensures that users can open the `VAT Books` report by applying a fix similar to [2]. [1]: https://github.com/odoo-dev/enterprise/commit/fd0afa474600586e8703ec377f962c8d7d94307a [2]: https://github.com/odoo/enterprise/blob/7362f1c5be7f496bdab660ed8fad37a6dd283616/account_reports/static/src/components/account_report/line_name/line_name.xml#L81 opw-6169697 opw-6170173 Forward-Port-Of: odoo/enterprise#115412
This update resolves visual inconsistencies and usability problems that arose after relocating benefit information within the employee contract section of Odoo Enterprise. The change improves the user experience when managing employee compensation and benefits, ensuring a cleaner and more intuitive interface.
Original PR description
Task: 6141770 Forward-Port-Of: odoo/enterprise#114765
This update fixes an issue where the IRN number, generated during e-invoicing, wasn't saved to the invoice itself. Now, the IRN number is correctly displayed in both the invoice PDF and the invoice form view after the EDI submission process. This ensures accurate record-keeping and compliance with Indian regulations.
Original PR description
**Steps to reproduce:** * Install module *Indian - GSTR with E-invoice (l10n_in_edi_gstr)*. * Configure *Indian integration* with required credentials (E-Invoicing, E-Way bill, etc.). * Save the…
**Steps to reproduce:** * Install module *Indian - GSTR with E-invoice (l10n_in_edi_gstr)*. * Configure *Indian integration* with required credentials (E-Invoicing, E-Way bill, etc.). * Save the settings. * Create a *customer invoice*. * Post the invoice. * Send the invoice through *E-Invoicing (EDI)*. * Open the generated *Invoice PDF* and the *form view*. **Observed behavior:** * The *IRN number* is correctly present in the *Invoice PDF*. * However, it is *not saved/displayed* in the invoice form view. **Cause:** * The invoice flow did not store the *IRN number* on the invoice after receiving the EDI response, even though the value was available. **Fix:** * Inherit *_l10n_in_edi_send_invoice*. * Add a condition after the invoice is sent and the JSON response is received. * When the *IRN number* is present in the response, set it on the *l10n_in_irn_number* field of the invoice (in lower case). opw-6097923 Forward-Port-Of: odoo/enterprise#115522 Forward-Port-Of: odoo/enterprise#114350
This update resolves an issue where the 'Create a Payslip' button wasn't functioning properly when no payslips were initially present. The fix corrects a technical error in the system's code, ensuring the button now reliably creates a new payslip when needed. This improves the W2 report generation process.
Original PR description
1.Install l10n_us_hr_payroll 2 Navigate to Payroll>Reporting>W2 Report. 3.Open/Create W2 form and try to add payslip by clicking "Add a line". 4."Create a payslip" button appears if their are no valid payslips. 5.Click it, it won't work! Root cause: - `onAdd` bind was missing in the controller - Renderer applied an additional `.bind(...)`, breaking the callback Fix: - Pass a dedicated `createNewPayslip` action from controller - Remove double binding in renderer - Forward callback directly to helper component task-[5928770](https://www.odoo.com/odoo/project/1251/tasks/5928770) Forward-Port-Of: odoo/enterprise#114263 Forward-Port-Of: odoo/enterprise#111735
This update corrects a bug that prevented users from successfully booking appointments with flexible hour slots in version 19.0. The issue stemmed from a rounding error in how appointment URLs were generated, leading to a 404 error. The fix ensures accurate slot durations are used, allowing for seamless appointment booking.
Original PR description
Steps to reproduce: 1. Install `appointment` 2. Create an appointment type with the followings 3. Schedule type flexible and a slot of 20 min. 4. Share this appointment and try to book appointment…
Steps to reproduce: 1. Install `appointment` 2. Create an appointment type with the followings 3. Schedule type flexible and a slot of 20 min. 4. Share this appointment and try to book appointment for 20 min. Issue: - 404 Error occurs after selectiong the slot Cause: - In 19.0, commit https://github.com/odoo/enterprise/commit/9bae0e13e7bf5e0db25a60fc2683bc51eccb4447 started using slot.duration when building the booking URL for flexible slots. However, slot.duration is rounded to 2 decimals, so a 20-minute slot is serialized as 0.33 instead of its exact value. During validation, the end datetime is recomputed from this rounded duration, which no longer matches the original slot boundaries. This mismatch causes the slot to be considered invalid and the controller raises NotFound. Solution: - Compute the slot duration directly from slot_start_dt_tz and slot_end_dt_tz when building the URL, preserving the full precision. opw-5924312 Forward-Port-Of: odoo/enterprise#108870
This update fixes an error in how emission factors are converted within the Odoo Enterprise ESG module. The previous process incorrectly handled unit and currency conversions, leading to inaccurate calculations. This change ensures that emission calculations are now precise and reliable.
Original PR description
Issue: ---------------------------------------- The conversions using Emission factors are done in the wrong way. Steps to reproduce: ---------------------------------------- - Install `esg` module - Create an Emission Factor from ton to kg of 1000 - Create a new Emission using the new factor, set the unit as kg - Notice the conversion is wrong Cause: ---------------------------------------- The two uom are inverted when calling `_compute_quantity()`. Same occured for the currencies. opw-6152413 Forward-Port-Of: odoo/enterprise#115575 Forward-Port-Of: odoo/enterprise#115246
This update resolves an issue where the IoT box pairing dialog could freeze indefinitely. Additionally, it corrects a display problem with language-specific placeholders, ensuring the IoT box is correctly recognized and usable across different languages. This improves the overall user experience for IoT device integration.
Original PR description
This commit fixes two small issues with IoT pairing: 1. When pairing an IoT box, even after the DB has discovered the IoT box and added it as a record, the dialog will keep waiting forever. If you close the dialog manually the IoT box appears as expected. 2. If using a language other than English, the placeholder 'Connecting' name will not be replaced when the IoT finishes pairing. The IoT box can still be used as normal however. Forward-Port-Of: odoo/enterprise#115627
This update resolves an issue where the POS system was loading all employees regardless of configuration. Now, the system only loads employees based on the POS setup, improving performance and reducing unnecessary data loading. This change ensures a smoother and more efficient POS experience.
Original PR description
Before this commit, when some employee was assigned to advanced or minimal employee, all of the employees were loaded in the POS session, because there was no basic employee assigned to the POS config. opw-5898068 Forward-Port-Of: odoo/enterprise#115109
This update ensures that modifying an employee's details in Belgium no longer affects their payroll information in India. Specifically, fields like Basic Salary and Fixed Allowance remain consistent, streamlining payroll processing and reducing the risk of errors. This change improves data accuracy and simplifies management for our Indian operations.
Original PR description
Changing an employee in Belgium should not affect the following fields in Indian payroll: Basic Salary percentage Basic Salary Fixed Allowance Fixed allowance percentage L10N In PF Employee Amount Employer task-6044787
This update removes the payment QR codes displayed on mobile versions of Odoo. Due to technical limitations, implementing a direct link to bank apps was not feasible without additional providers. The QR codes have been hidden on mobile to improve the user experience.
Original PR description
When a payment meets few conditions, we display a qr code to invite the user to scan it with his bank app. But in mobile it doesn't make sens. We would like to implement a link instead, so the user can open his bank app directly from odoo, but it doesn't seems doable for free without any providers. We will hide the qr code on mobile displays for now. task-4563391 Linked:https://github.com/odoo/odoo/pull/255486
This update corrects a bug in the overtime tour within the Odoo Enterprise system. Previously, the tour incorrectly targeted an input field, leading to unintended interactions. This fix ensures the tour accurately directs users through the overtime ruleset flow.
Original PR description
The tour previously matched the input field underneath the popup and interacted with the wrong element, the fix scope the selector to the modal. task-6172067 Forward-Port-Of: odoo/enterprise#115458
This update adds comprehensive tests for the new customer rating functionality introduced in odoo/enterprise#109696. The tests ensure that rating emails are only sent when appropriate (slot completion or report signing) and that the rating process itself functions correctly. This improves the reliability and accuracy of customer feedback collection.
Original PR description
This commit adds tests for the customer ratings flow introduced in odoo/enterprise#109696. Specifically, it checks that the customer rating request email is only sent upon completing the slot, or after signing the customer report. It also tests the rating itself. task-6147846 Forward-Port-Of: odoo/enterprise#114834
This update fixes an issue where leave calculations were incorrectly recomputed due to outdated employee version references. The change ensures that time off calculations now accurately reflect the employee's active status at the time the leave was created, leading to more reliable time off reporting.
Original PR description
The employee_type_id, job_id and structure_type_id fields on hr.leave were stored related fields pointing to current_version_id. This caused all time offs to be recomputed whenever the employee's current version changed, and stored the current version's values instead of those active at the time of the leave. Replace the related fields with a compute based on date_from, resolving the version active at the leave's start date. task-6175086 Forward-Port-Of: odoo/enterprise#115607
This update makes the timesheet assistant view more user-friendly by implementing small adjustments for better clarity. These changes enhance the overall experience for users managing their timesheets within the Odoo Enterprise system. The update focuses on improving usability and streamlining the assistant view.
Original PR description
Improve the assistant view with small adjustments to enhance clarity and user‑friendliness. Forward-Port-Of: odoo/enterprise#115573 Forward-Port-Of: odoo/enterprise#114339
This update resolves a bug where portal users were incorrectly seeing the 'View Timesheets' button, even without the necessary permissions. The fix involved updating how the system determines access to timesheets, ensuring only authorized users can see this option.
Original PR description
**Issue:** The 'View Timesheets' button is shown to the portal user even though they don’t have access to view timesheets. Currently, we have added _sale_order_get_page_view_values in the sale module, which is overridden in sale_timesheet. We are using it here. task-4745519 Forward-Port-Of: odoo/enterprise#115620 Forward-Port-Of: odoo/enterprise#113481
This update resolves a technical issue within the Odoo Enterprise system's point-of-sale (POS) functionality. Specifically, a misconfigured import statement was corrected, ensuring proper operation of the adam_scale driver. This change improves system stability and reliability.
Original PR description
This PR fixes the wrong import in adam_scale_driver.py opw-6173563 Forward-Port-Of: odoo/enterprise#115625
2 changes
Resolved issues and error corrections
This update resolves an issue where attachments weren't uploading reliably when navigating between records in the chatter. The fix ensures attachments are correctly associated with the intended record, preventing data inconsistencies and improving the attachment upload experience. This improves data integrity and user confidence.
Original PR description
Currently, when uploading a bunch of attachments or a big one to the chatter, if you click on the pager (e.g. next) before the upload is complete, the attachments that have not yet been uploaded are uploaded to the next record. Due to the persistence of the Chatter component during record navigation and the fact that the `FileUploader` logic is tied to `state.thread`, an async callback that finishes after a record switch will attempt to update the currently active thread rather than the one that initiated the upload. With this change we tie uploader lifecycle to a specific record and ensure the completion callback only affects that record. task-5119290
This update resolves an issue where vendor bills were incorrectly grouped in journal entries, appearing in multiple statuses. The fix adds a necessary search method to the 'status_in_payment' field, ensuring accurate grouping and reporting based on bill status. This improves the reliability of financial data analysis.
Original PR description
Step to reproduce - create a vendor bill, for say 100$ i.e Bill 1 - post it - go to journal entry menu - group by: "status_in_payment" - expand the lines Observation: - after group by, suppose we get 2 groups in journal entry (Draft, Not Paid) - when we expand. Bill 1 is present in both group (Bill 1 should be in Not paid) - in each group we get all the records Cause: - `status_in_payment` is a compute field, for web_search to work, this fields need a `search` method which is absent here. - in this case, we just set domain = [] - hence, we got above unexpected results https://github.com/odoo/odoo/blob/e7f4a88432d9696800d1f2b9e28bf92320c97422/odoo/osv/expression.py#L1179-L1187 Fix: - Add the search method for this fields opw-6109572 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
1 change
Resolved issues and error corrections
This fix addresses an error that occurred when users attempted to process multiple refunds for the same customer within a single payment transaction. The change prevents users from selecting multiple refunds, ensuring the system functions correctly and avoids data inconsistencies. This improves the reliability of the point-of-sale refund process.
Original PR description
After the fix, when selecting multiple refunds not belonging to a same order, a user error will appear, preventing an odoo error later in the flow.…
After the fix, when selecting multiple refunds not belonging to
a same order, a user error will appear, preventing an odoo
error later in the flow.
_____________________________________________________
## Short functional explanation of the error
Selecting several refunds from the same customer in the same transaction, and making sure to print an invoice at every operation caused an error.
## Reproduction Steps
1. Go to the point of sales module, and create an order for a specific customer. Proceed to the payment and make sure that finalizing the payment will create an invoice, before confirming the payment.
2. Create a second order for the same customer, and proceed the same way as in step 1.
3. On the product screen, click on "refund".
4. Select one order that you've just completed. Then, setup the quantity at 1 and click on refund.
5. Do step 4 again but this time, select the second order that you've just completed.
6. Click on payment, then click on invoice then try to validate the payment.
The error occurs:
Expected singleton: account.move(720, 722)
Traceback (most recent call last):
File "/data/build/odoo/odoo/models.py", line 5896, in ensure_one
_id, = self._ids
ValueError: too many values to unpack (expected 1)
## Causes of the problem
It is due to an ensure_one() in python. Indeed, in the file point_of_sale/models/pos_order.py,in the function _prepare_invoice_vals(self), an error occured on the line:
vals['ref'] = _('Reversal of: %s', self.refunded_order_ids.account_move.name)
self.refunded_order_ids.account_move.name is supposed to be a singleton, but in the case where a transaction has several refund order, this isn't the case anymore, causing the error.
## Explanation of the fix
After the fix, when you select a second refund after selecting one, the previous one will be replaced by the current one, preventing users to select 2 refunds in the same transaction. In the code, this is translated as:
in the point_of_sale/static/src/app/screens/ticket_screen.js file, in the onDoRefund() function, when a refund (= orderline) is created, we check that there are less than 2. If not, we remove the previous ones.
______________________________________________________________
opw-4791231
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