Daily updates from Odoo
Thursday, April 30, 2026
233 changes
16 changes
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
26 changes
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
This update resolves an issue where users without HR access rights couldn't apply filters in the Time Off search functionality. The fix prevents a technical error related to a specific field not present in the public employee model, ensuring all users can effectively filter their time off data. This improves usability for a wider range of users.
Original PR description
More general fix for https://github.com/odoo/enterprise/pull/113973 or https://github.com/odoo/enterprise/pull/115478 Steps to reproduce: - Log using a user with no HR access rights (e.g. Marc Demo) - Go to Time Off > Overview - Remove all filters - Add a new custom filter on "Department is equal to ..." or "Job is equal to ..." Instead of the filter being applied, a traceback occurs. This originates from the fact that in _get_gantt_data_groupby_employee, the employee domain is mapped to address the field current_version_id. However, if a user has no HR rights, the search will be redirected to the employee public model, on which that field isn't defined. This commit adapts the domain in search_fetch to avoid current_version_id being present in it. No related task Co-authored by @BeBel42
This update adds a new test case to the HR holiday Gantt chart functionality. It addresses a previous issue related to public employee access, ensuring that authorized users can correctly view and manage holiday schedules. This enhancement improves the reliability and security of the HR module.
Original PR description
Add a test for the issue resolved in https://github.com/odoo/odoo/pull/261937 No related task
A bug was causing timesheets to be incorrectly linked to another employee when created through the timesheet systray. This issue stemmed from a formatting error in how user IDs were passed during the timesheet creation process. This fix ensures timesheets are accurately recorded for the correct employee.
Original PR description
# Steps to reproduce: - Open a billable project and a task - Open the timesheet systray - Create timesheet # Current behaviour The timesheet is recorded for another employee. # Root cause This happens because the `user_id` passed to the record update was lacking the right `[id, name]` format. As a consequence, the timesheet was created without a user (`False`), thereby linking it to another employee than the current user. task-6169253
This update fixes a discrepancy in the sale details report by accurately reflecting cash rounding adjustments. Now, the report displays the total cash rounding applied during a session, aligning the displayed total with actual payment amounts. This ensures greater accuracy and transparency in sales reporting.
Original PR description
The sale details report total_paid was computed from sum(order.amount_total), which does not include the cash rounding adjustment. This caused a discrepancy between the displayed total and the sum of individual payment lines when cash rounding is enabled. Use the sum of actual payment amounts instead, which naturally includes cash rounding since payments are recorded with their rounded values. opw-5253018 Forward-Port-Of: odoo/odoo#261884 Forward-Port-Of: odoo/odoo#254401
This update resolves an issue where 'Other Expense' accounts were incorrectly included in default reporting filters. By adding specific account types (exchange differences, discounts) to the filter, the system now accurately categorizes expenses, leading to more precise financial reporting. This improves the reliability of financial data.
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
This update resolves a problem where the size of the product search bar was incorrectly set, causing issues with a website tour. The fix ensures the search bar's size is only adjusted when the ‘website_sale_renting’ module is installed, preventing disruptions to other website features.
Original PR description
__Before commit__ odoo/enterprise@1111381c set the size attribute of the product search bar. However, the view inherits from `website.website_search_box`, which means that all search boxes on the website will have the size attribute set if `website_sale_renting` is installed. The tour `dropdowns_and_header_hide_on_scroll` fails in saas-19.3 because odoo/odoo@9394e17a added a step that depends on the size of the main website search bar, which may vary because of this. __After commit__ Only set the size attribute to the product search bar as intended. runbot-242449 Forward-Port-Of: odoo/enterprise#115433
19 changes
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
This update resolves a visual bug where the "Add to Cart" button appeared squeezed on product pages in edit mode. Specifically, when the Image Area is set to 33 and the purchase style is Large, the button's size was incorrect. The fix ensures the button displays its intended size across all product page layouts.
Original PR description
This code fixes a bug related to the size of the “Add to Cart” button. To reproduce the bug, you need to be on a product page in edit mode. In this mode, you must set the Image Area to 33 and the purchase style to Large. You will see that the “Add to Cart” button is squeezed. The bug occurs because, in edit mode, a new span container is added around the button to indicate that it can be edited. The fix simply adds CSS on top of this container. find-when-working-on-task-6147939 **Before** <img width="1918" height="552" alt="before" src="https://github.com/user-attachments/assets/f46c78ff-b095-4738-821b-ff52272f160d" /> **After** <img width="1913" height="1054" alt="after" src="https://github.com/user-attachments/assets/ef38a68f-acbb-439b-883d-8e3ee45c5d4a" />
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
1 change
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
20 changes
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
This update fixes an issue where outstanding amounts weren't accurately calculated after a refund was processed within a point-of-sale transaction. Previously, only the original order total was considered. Now, refund orders are included, ensuring the correct net due amount is displayed and settled, improving financial accuracy.
Original PR description
Step to reproduce - install "pos_settle_due" - have a customer, A and a pos with payment method "customer Account" - start pos, add 3 qty of product with unit price 10$ with partner A - use payment method "customer Account" i.e. of type "pay_later" (do not invoice orders) - refund 1 qty of previous order using same payment method - go to partner list, notice A has 20$ as due - click on "hamburger btn" > settle due amount Observation: - notice we only get the order amount as due i.e order with 30$ - we should have received the refund order too, so that net due of 20$ can be processed Cause: - currently, we didn't considered refunds orders at all, when settling dues Fix: - now we consider order with total < 0 i.e refund orders to be included for settlement opw-5869313 Forward-Port-Of: odoo/enterprise#114143 Forward-Port-Of: odoo/enterprise#107883
5 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
This update ensures correct handling of vendor identification when importing KSeF bills. It now requires the Polish NIP number (without the 'PL' prefix) to be used, aligning with Polish tax regulations for foreign companies operating in Poland. This is crucial for proper KSeF compliance and accurate invoice processing.
Original PR description
When we import bills from KSeF, the vendor (`Podmiot1`) XML tag must include a Polish `NIP` number XML tag. The `NIP` is the base number composing a polish `vat` number, but without the prefix `PL`.…
When we import bills from KSeF, the vendor (`Podmiot1`) XML tag must include a Polish `NIP` number XML tag. The `NIP` is the base number composing a polish `vat` number, but without the prefix `PL`. This is true even if the vendor is from another country like Luxembourg: if they have a stable organization in Poland and sells in Poland - then they have to use a polish `NIP` to use the KSeF and issue their invoices. Two issues: - We search the vendor by `NIP` as it was a `vat` number, but we add the `vendor_country` code as prefix instead of `PL`. I.e. we search for `LU012345678` instead of `PL012345678`. - When we don't find the vendor in the database, we create one using the `NIP` number coming straight from the tag, as it was a `vat` number. I.e. for a partner in Luxembourg, `vat` will become `LU012345678` instead of `PL012345678` ref: https://ksef.podatki.gov.pl/media/4u1bmhx4/information-sheet-on-the-fa-3-logical-structure.pdf Ticket [link](https://www.odoo.com/odoo/project.task/6148039) opw-6148039
This update resolves a technical issue where long descriptions in related image fields caused website errors (502 errors). The fix truncates filenames to prevent exceeding server buffer limits, ensuring images load correctly for users. This improves the overall user experience and prevents potential website downtime.
Original PR description
## Problem: When generating a filename for a related studio image field, if the `name` is excessively long, the response header may exceed nginx's buffer size of 4kb, causing the request to fail. ## Solution: We will truncate the assigned filename for binary streams to the first 255 characters of whatever the assigned name would have been. ## Steps to reproduce (Runbot 18): 1. Open Studio editor on a Sales Order 2. Edit List View on Sale Order Lines 3. + Related Field, Product > Image, image widget 4. Make the description very long (close to 4000 characters) 5. Note the image will not load for that SOL, and the network tab shows a 502 error opw-5360952
This update resolves an issue where the Swedish EC Sales Report exported to KVR (a key accounting format) displayed decimal values instead of the required integer format. This fix ensures accurate reporting for Swedish businesses, aligning with local tax regulations and improving data integrity.
Original PR description
**PROBLEM** EC Sales Report in Sweden needs to be reported with integer values. **STEP TO REPRODUCE** 1. Install l10n_se 2. On the se company, create a invoice with lines with EU tax and confirm it. 3. Go to Accounting/Reporting/EC Sale List and export to KVR. 4. Notices the KVR uses numbers with decimals places. opw-6045289 Forward-Port-Of: odoo/enterprise#114292
3 changes
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-prThis update fixes a bug preventing changes to Sales Orders (customer, state) in draft mode from being logged in the chatter. The previous system suppressed all tracking data, but this change ensures that user-initiated modifications are accurately recorded for better auditability and communication. This improves transparency and collaboration around sales order updates.
Original PR description
**Problem:** Changes to tracked fields (customer, state) on draft Sales Orders are not logged in the chatter, even though these fields have `tracking` enabled. **Steps to reproduce:** 1. Create a…
**Problem:** Changes to tracked fields (customer, state) on draft Sales Orders are not logged in the chatter, even though these fields have `tracking` enabled. **Steps to reproduce:** 1. Create a Sales Order, do not confirm 2. Change the customer → no log in chatter 3. Confirm the SO, then cancel it 4. Set it back to Quotation → no log in chatter **Current behavior:** No chatter entry is created for either change. **Expected behavior:** Both changes should appear in the chatter since `partner_id` (tracking=1) and `state` (tracking=3) have tracking enabled. **Cause of the issue:** `_track_finalize` discards ALL tracking data whenever the SO is in `draft` state. This was originally intended to avoid noise from catalog product additions, but it also suppresses legitimate field changes like customer updates and state transitions back to draft. **Fix:** Instead of blanket-suppressing all tracking on draft SOs, only discard tracking when the change originates from the product catalog (`_update_order_line_info`), which sets a `catalog_skip_tracking` context flag. This preserves the original noise-reduction intent while allowing real user-initiated field changes to be tracked. Backport of: 311bf3426fb241cd5036db58c6c317fe0e81ab87 opw-6106537
This update fixes a potential error in the Danish tax reporting module that could cause unexpected application crashes. The issue stemmed from a mismatch between how error messages were handled and the expected data type, specifically related to string formatting. The fix includes added tests and resolves the problem, ensuring more stable reporting.
Original PR description
before this commit, if the SKU server was returning an error message, the error handler would raise an exception because of the lazyTranslate. The reason is that `join()` expects an actual sting as argument, not a lazy string. This commit adds some tests for the error case and fixes the error due to the lazytranslate in the error codes. opw-6171466