Daily updates from Odoo
Navigate
Branch
Thursday, April 16, 2026
193 changes
22 changes
New functionality added to Odoo
This update adds a guided tour for Worldline payment terminals when used with kiosks. This ensures seamless and correct payment processing, addressing a previous issue and enhancing the kiosk ordering experience for customers. It's a key improvement for supporting our retail partners' self-service solutions.
Original PR description
We add a tour to ensure worldline payment terminals work correctly with kiosk. Forward-Port-Of: odoo/enterprise#113823 Forward-Port-Of: odoo/enterprise#105478
This update introduces a new password field widget for Odoo, allowing users to securely enter sensitive information like passwords. The widget hides the input field by default, providing an 'eye' icon to reveal the typed value, ensuring data privacy and compliance with security standards. This addition enhances the security and flexibility of Odoo forms and views.
Original PR description
This commit introduces a new "password" field widget. This widget can be set on char and text fields. It renders the value inside an input with `type="password"` such that the real value is hidden. Next to the input, an "eye" is displayed and allows to show the real value. The widget can be used in form, list and kanban views. Such a widget is sometimes necessary to be security compliant. Task~6116365 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#258887
Enhancements to existing features
This update enhances the Point of Sale system by adding sound feedback during barcode scans. A pleasant beep confirms successful product identification, while a distinct error sound alerts staff to scanning failures. This improves user experience and reduces potential errors during transactions.
Original PR description
Play a beep sound when a barcode scan successfully finds a product, partner, or GS1 barcode. Play a distinct error sound when the scan fails to match any record. task-id: 5969010 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250434
Resolved issues and error corrections
This update resolves an issue where the Sales/Purchase Tax Report was incorrectly displaying doubled VAT amounts for invoices using 'Imported VAT' taxes. The fix replaces a problematic calculation method to accurately sum VAT amounts, ensuring financial reports are reliable. This improves the accuracy of VAT reporting for Vietnamese businesses.
Original PR description
The Sales/Purchase Tax Report showed doubled untaxed amounts and VAT amounts for bills using import VAT group taxes (e.g. "Imported VAT 10%"). The root cause: accessing `tag_t.balance_negate` in the SQL queries triggered a LEFT JOIN on `account_report_expression` (via `_compute_sql_balance_negate`). The Form 01/GTGT report references import VAT tags in two expressions (the parent line and the "including imported" sub-line), so this JOIN produced two rows per account move line, causing GROUP BY to double the SUM. Fix: replace `balance_negate` with a `balance_sign` option (-1 for sales, +1 for purchase) set in each handler's initializer to avoid the problematic JOIN. task-6083697
This update fixes an issue where invoice periods were incorrectly calculated when subscriptions started on the 1st of a month and 'Align to Period Start' was enabled. The fix ensures invoices accurately reflect the subscription's billing cycle, displaying the correct month and date range. This improves invoice accuracy and reduces potential billing discrepancies.
Original PR description
Steps to reproduce: ------------------------------------- 1. Install the Subscription module. 2. Go to Subscription > Configuration > Recurring Plans. * Open a Monthly recurring plan and enable Align…
Steps to reproduce: ------------------------------------- 1. Install the Subscription module. 2. Go to Subscription > Configuration > Recurring Plans. * Open a Monthly recurring plan and enable Align to Period Start. 3. Create a new Subscription: * Select the configured monthly plan. * Add any subscription product. * In the Other Info tab, set a Start Date in the past on the 1st day of a month (e.g., 01/11/2025). 4. Confirm the subscription. 5. Create a draft invoice. Observation: ----------------------------------- In the invoice line, you see the message: `61 days 11/01/2025 to 12/31/2025` It should be: `1 Month 11/01/2025 to 11/30/2025` Issue: ----------------------------------- https://github.com/odoo/enterprise/blob/a5a76de5f25483afa5432ed333c48d78832f128c/sale_subscription/models/sale_order_line.py#L376-L378 In `_get_invoice_line_parameters`, the computation attempts to find the next 1st day of the month However, `new_period_stop` already includes the billing period. When `new_period_stop` is in the past, an extra month is added through `new_period_stop + relativedelta(months=1)`, resulting in an incorrect period range Solution: ----------------------------------- Use `new_period_start` as the anchor point for period computation. Ensure the billing period ends on the last day of the starting month when Align to Period Start is enabled For upsell orders, the fix is NOT applied because for upsells, `new_period_stop` is already set to the parent subscription's `next_invoice_date`, which represents the correct billing boundary. opw-5920036 Forward-Port-Of: odoo/enterprise#107407
This update ensures that users on MacOS can correctly post and edit messages in Odoo Chatter using the CMD-Enter key shortcut. Previously, the system displayed the outdated CTRL-Enter hint. This change improves the user experience for MacOS users and aligns the shortcut with the composer's functionality.
Original PR description
Recent commit changed the shortcut in MacOS for posting and editing message to CMD-Enter, instead of CTRL-Enter [1]. The hint was changed in the composer to post message, but the hint when editing message was still showing "CTRL-Enter" instead of "CMD-Enter", which this commit fixes. [1]: https://github.com/odoo/odoo/pull/248862 Task-6124496 Before / After <img width="904" height="116" alt="Screenshot 2026-04-15 at 14 04 34" src="https://github.com/user-attachments/assets/a7ad0450-f110-45b1-82c8-d6d251625ca1" /> <img width="894" height="119" alt="Screenshot 2026-04-15 at 14 03 53" src="https://github.com/user-attachments/assets/770b13b9-d882-4ea8-9fe3-f4b334de78ba" />
This update corrects a technical issue preventing Odoo from correctly identifying Swedish bank accounts. The fix adds a necessary decorator to the method used by the bank account widget, ensuring proper communication with banks. This resolves a potential error that could have impacted users in Sweden.
Original PR description
The override of `retrieve_account_type` was missing `@api.model`. (the same as Argentinian and Australian overrides) Since this method is called through RPC from the bank account widget, Odoo expected a model method signature. Without the decorator, the call could fail with a missing `acc_number` argument. Add the missing decorator so Swedish account number detection works properly. opw-6002770
This update fixes an error in how Odoo calculates the available capacity for appointments booked through Google Reserve. Previously, the system reserved the full party size for each resource, leading to overbooking. The fix ensures accurate capacity allocation, preventing double-booking and improving appointment scheduling efficiency.
Original PR description
The current logic inside the appointment google reserve controller to compute reserved and used capacity per resource was incorrect. It was reserving the full party size for each resource instead of properly computing how much spots we are reserving for each. The code was fixed and a test was adapted for proper coverage. Task-6120016 Forward-Port-Of: odoo/enterprise#113908 Forward-Port-Of: odoo/enterprise#113805
This update ensures that the date range used to fetch transactions from iap is always accurate. Previously, incorrect dates could be used, leading to missing transactions. This change now uses the latest statement or statement line date, guaranteeing complete and reliable transaction retrieval.
Original PR description
To fetch transactions from iap, we have to give a date from. Before this commit, it was possible to have a date from prior the lock date which is not supposed to happen. This commit will do the max between the lock date the last date of either the statement or the statement line. task-6019584 Forward-Port-Of: odoo/enterprise#110010
This update fixes a problem where the REAGYP compensation amount wasn't being correctly included in the deductible quota submitted to the Spanish tax authority (AEAT). The change ensures that all relevant tax deductions are accurately reported, improving compliance with Spanish regulations. A related test was updated to reflect the new calculation.
Original PR description
Currently, the deducible amount for REAGYP is not passing through to the AEAT. This happens because the REAGYP compensation amount (ImporteCompensacionREAGYP) was missing from the total deductible quota calculation in the SII JSON payload. To fix this, we add 'sujeto_agricultura' to the list that cheks if the tax value for l10n_es is in the list task-6072773 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259232 Forward-Port-Of: odoo/odoo#256586
This update fixes an issue where recruitment officers couldn't view job tracker information. The change ensures officers have direct access to this feature through their designated role, simplifying the recruitment process and eliminating the need for additional employee permissions. This improves efficiency and streamlines workflows for the recruitment team.
Original PR description
Steps to reproduce: ---------------------------------------- 1. Install the `hr_recruitment` module 2. Create a new user and configure the following access rights: * Employees: No * Recruitment:…
Steps to reproduce:
----------------------------------------
1. Install the `hr_recruitment` module
2. Create a new user and configure the following access rights:
* Employees: No
* Recruitment: Officer Manage all applicants
3. Create new job position > Set created user in Recruiter
4. Log in with the created user
5. Go to Recruitment > Click on the Configure button of that job position
Observation:
----------------------------------------
The Trackers page is not visible on the job position form for the recruitment officer user.
If the user is additionally granted the Employees → Officer: Manage all employees group, the Trackers page becomes visible. The access to the recruitment Trackers should not depend on the Employee 'Officer: Manage all employees' access right.
Issue:
----------------------------------------
The visibility of the Trackers page depends on the Employees → Officer: Manage all employees group instead of the recruitment officer access rights
Solution:
----------------------------------------
Grant access to the Trackers page using the Recruitment Officer group so recruitment officers can access it without requiring the employee officer privileges
opw-5969416
Forward-Port-Of: odoo/odoo#252209This update fixes an issue where changing tax groups could cause errors due to account updates. The change prevents unnecessary account updates during tax group modifications, ensuring data consistency and preventing potential constraints. This improves stability and reduces the risk of errors when managing tax groups.
Original PR description
Upon chart reload, accounts will not be updated (except for tax_ids), but tax groups are. If a tax group was changed to relate to a different account and this account was re-purposed (e.g.…
Upon chart reload, accounts will not be updated (except for tax_ids), but tax groups are. If a tax group was changed to relate to a different account and this account was re-purposed (e.g. account_type changed from an incompatible to a compatible type, the fact that the account is not updated will trigger constraints in the tax group when it is written. IOW, if the purpose of an account is not changed, its use should not be changed either. E.g.: 1f4710deb206736cd71580d8fd95552d9b7c8014 changed the value of `tax_payable_account_id` on tax group `tax_group_cofins_incl_goods` to `account_template_202011005` and the same commit changed the value of `account_type` on `account_template_202011005` from `liability_non_current` to `liability_payable`, triggering `_constrains_payable_receivable_account` (in 19.2: https://github.com/odoo/odoo/blob/e00dd21880c3c4e5c22d65567c700e02541f7259/addons/account/models/account_tax.py#L68). So here, we skip the update of relations to accounts on tax groups, if the account already exists. Forward-Port-Of: odoo/odoo#259160
This update fixes an issue where the event ticket download button wasn't appearing for orders processed with online payments. The fix ensures that necessary data is always set, regardless of the payment method, allowing users to download their tickets seamlessly after completing the purchase. This improves the customer experience for online event ticket sales.
Original PR description
**Steps to reproduce:** - Set up an event, go put it's state to Annonced - Set up any online payment method (Demo also triggers the bug) - Go to a PoS that sells the event tickets - Purchase one and…
**Steps to reproduce:** - Set up an event, go put it's state to Annonced - Set up any online payment method (Demo also triggers the bug) - Go to a PoS that sells the event tickets - Purchase one and pay with the online payment method - Once on the ticket screen, the button to download the event tickets is not displayed **Why the fix:** The normal flow only works for offline payment methods, because we check if the ordered is either paid or invoiced before setting all the values needed by the frontend regarding the ticket registration. The problem is that with an online payment method, once we enter the **read_pos_data** method that sets the values for the frontend, the order is still in draft, so we just return without doing anything. We now set the values regardless of the order's status and send the confirmation mail in the same way as if it was an online payment. In the case of an online payment, the mail will be sent by the **action_pos_order_paid** function that is called once the payment is processed. A test might be a bit weird to make as we don't have a bridge for pos_online_payment and pos_event, and that we would need to mock the server's answer to be able to pay for the online payment and check that we have the needed values. So the setup for pos_event would have to be copied into pos_online_payment to test it and it would only be ran if both modules are installed. opw-5438432 Forward-Port-Of: odoo/odoo#258986 Forward-Port-Of: odoo/odoo#249306
This update resolves a technical issue that prevented demo mode from functioning correctly after the addition of Peppol and Nemhandel response data. The fix ensures demo flows run smoothly by adapting the mock data, preventing errors and improving the demo experience.
Original PR description
With the recent addition of responses in Peppol and Nemhandel, we forgot to adapt the mocking data for demo flows, which resulted in tracebacks in demo mode. Forward-Port-Of: odoo/odoo#258655
This update corrects a bug in the Helpdesk module where priority filters weren't working correctly. A recent change caused the priority filter to become nested, leading to all tickets being displayed instead of just those with high or urgent priority. This fix ensures priority filters function as intended, improving ticket organization and prioritization.
Original PR description
Steps to reproduce: - Install Helpdesk. - Click on the High/Urgent priority filter. Issue: - All tickets are shown instead of only filtered priority tickets. cause: - Priority filter became nested after changes in pr https://github.com/odoo/enterprise/pull/105481 Fix: - Adjust the filter handling to correctly apply the nested priority filter domain. task-6089715
This update resolves a bug that caused the Time Off dashboard to crash when a new company or localization was created with no existing time off records. The fix prevents the system from attempting to fetch data when no data is available, avoiding a critical error.
Original PR description
Steps to reproduce: 1. Create a new company or install a localization (resulting in 0 time off records). 2. Open the Time Off overview (defaults to the Dashboard Gantt view). -> OwlError: Cannot…
Steps to reproduce: 1. Create a new company or install a localization (resulting in 0 time off records). 2. Open the Time Off overview (defaults to the Dashboard Gantt view). -> OwlError: Cannot destructure property 'type' of 'fields[fieldName]' as it is undefined. Cause: Following the recent work entries refactoring, the JS function `_fetchUserFavoritesWorkEntries` was added to the base `HrHolidaysGanttModel` to fetch data from the `hr.leave` model. When the Dashboard (`hr.leave.report.calendar`) has 0 records, the frontend `SampleServer` is activated to generate fake background data. It builds its schema based on the Dashboard view. When the JS unconditionally fires the cross-model RPC call to `hr.leave` (grouping by `work_entry_type_id`), the `SampleServer` intercepts it. Because it doesn't have `work_entry_type_id` in its Dashboard schema, it fails to evaluate the field type and crashes the Owl lifecycle. Solution: Restrict the `_fetchUserFavoritesWorkEntries` call in `_fetchData` so it only runs when not using sample data (`!this.useSampleModel`). This prevents the `SampleServer` from intercepting unsupported cross-model queries to `hr.leave` when loading empty views on fresh databases. task-5969290
This update fixes an issue where the Envia delivery integration incorrectly processed zip codes in Colombia. By using Envia's geocoding service, the system now accurately transmits the required municipality codes, ensuring correct delivery addresses and improving the reliability of shipments within Colombia. This resolves a previous data processing error.
Original PR description
For Colombia, Envia expects the municipality/DANE-style code in the address payload, not the raw postal code. When `l10n_co_edi` was not installed, the Envia integration fell back to the partner zip code and padded it locally before sending it as both `postalCode` and `city`. This produced incorrect values such as turning the Ibagué zip code `730001` into `73000100`, while Envia geocodes resolves that zip code to `73001000`. Use Envia geocodes to resolve the Colombia zip fallback and retrieve the `stat_8digit` code expected by Envia instead of deriving it locally. opw-6083181 Forward-Port-Of: odoo/enterprise#112838
This update resolves an issue preventing users from generating session reports in the CO company setting. The fix addresses a technical error related to accessing sale details, ensuring the report generation process now functions correctly. This improves the usability of the point-of-sale system for CO businesses.
Original PR description
Currently when trying to generate the session report a traceback appears. Steps to reproduce: ------------------- * Install l10n_co_edi_pos * Switch to CO company * Open pos session * Make a sale * Close register * Generate session report > Traceback Why the fix: ------------ We get the sale details with: https://github.com/odoo/odoo/blob/0ce5baf2918960591284eb494d82dfef07043af0/addons/point_of_sale/models/report_sale_details.py#L429-L430 Where the config ids given to `get_sale_details` are given here https://github.com/odoo/odoo/blob/0ce5baf2918960591284eb494d82dfef07043af0/addons/point_of_sale/models/report_sale_details.py#L413-L414 From there we can't access any field from a list of number. opw-6049484 Forward-Port-Of: odoo/enterprise#111627
This update resolves a bug where the state of a date field in forms was incorrectly being reset after saving. Typing a date into the field and saving would sometimes revert to a previous value. The fix ensures the date field's state is correctly updated immediately after the datepicker is closed, preventing data inconsistencies.
Original PR description
Step to reproduce: - Go on view form with a date field - Set the date with the input by typing the date with day and month (mm/dd or dd/mm), then press enter - Save the record - Redo the second step by with a different date - Save the record The assignation of the state.value done when closing the datepicker is useless and can put old a value in the state. The datepicker hasn't finished to update of the record that the assignation put back the old value of the record back in the state. The reason why it happens only after a save is still unknown. task-6095467 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258111
This update fixes an issue where the 'My department' filter in holiday reporting was incorrectly showing employees with past versions of their department assignments. The change now only considers current department assignments, ensuring accurate holiday reporting for all employees. This improves the reliability of time-off data.
Original PR description
Reproduce the issue: - Create an employee linked to a user with department A - Create a second employee with 2 versions: - a past one with department A - a current one with department B - create a leave for both employees - go to Time Off > Overview, keep the group by employee and select the filter "My department" - both employee appear Before this commit, the search on "member_of_department" was looking for all versions with a similar department (same or child of) regardless of the version validity. This commit limits that search to current versions only task-6076014 Forward-Port-Of: odoo/odoo#256388
This update fixes a problem where combo prices were incorrectly doubling when multiple items were added to a sale. The change ensures that free items and parent unit prices are accurately recalculated during pricelist updates, resulting in correct pricing for combo orders. This improves the reliability of point-of-sale transactions.
Original PR description
Fix combo prices doubling when quantity > 1 during pricelist changes. Correctly scale free items in 'getFreeAndExtraChildLines' and ensure parent unit prices are updated in 'setPricelist'. task-id: 5971935 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250666
This update resolves an issue where the system was incorrectly calculating payroll neutralization in Switzerland. The fix ensures accurate reporting of neutralized amounts, which is crucial for compliance with Swiss tax regulations. This change improves the reliability of payroll data for our Swiss clients.
Original PR description
Forward-Port-Of: odoo/enterprise#113961
16 changes
New functionality added to Odoo
This update introduces a new password field widget for Odoo, allowing users to securely enter sensitive information like passwords. This widget hides the input field by default, providing an 'eye' icon to reveal the typed value, ensuring compliance with security standards. It can be used across various Odoo views.
Original PR description
This commit introduces a new "password" field widget. This widget can be set on char and text fields. It renders the value inside an input with `type="password"` such that the real value is hidden. Next to the input, an "eye" is displayed and allows to show the real value. The widget can be used in form, list and kanban views. Such a widget is sometimes necessary to be security compliant. Task~6116365 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#258887
Enhancements to existing features
This update enhances the Point of Sale system by providing audible feedback during barcode scans. A pleasant beep confirms successful product identification, while a distinct error sound alerts users to scanning failures. This improves the user experience and reduces potential errors during transactions.
Original PR description
Play a beep sound when a barcode scan successfully finds a product, partner, or GS1 barcode. Play a distinct error sound when the scan fails to match any record. task-id: 5969010 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250434
This update fixes an issue where product names on the Replenishment dashboard were being cut off, leading to a poor user experience. The team adjusted column sizes to maximize space and ensure product names are fully visible, improving usability.
Original PR description
Purpose: the name of the product in the replenishment dashboard often gets truncated which is bad for UX. Adjust column widths to make better use of space. task-5097352 Forward-Port-Of: odoo/odoo#253384
This update simplifies the balance sheet structure in both the generic and US versions of Odoo. It clearly separates 'Earnings' and 'Equity' accounts, making it easier to track financial performance and improve reporting accuracy. This change enhances the clarity of financial statements.
Original PR description
Simplifying the structure of the Balance Sheet in order to distinguish clearly **Earnings** and **Equity**, in the generic and US balance sheet. Improving the generic and us charts of accounts to better highlight the account pair for the allocation of earnings. task-6053852 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256674
This update simplifies the Balance Sheet report to clearly separate Earnings and Equity, enhancing financial reporting for both the standard and US versions of Odoo. The changes improve the presentation of key financial accounts, making it easier to understand and analyze financial performance.
Original PR description
Simplifying the structure of the Balance Sheet in order to distinguish clearly **Earnings** and **Equity**, in the generic and US balance sheet. Improving the generic and us charts of accounts to better highlight the account pair for the allocation of earnings. task-6053852 Forward-Port-Of: odoo/enterprise#112499
Resolved issues and error corrections
This update fixes an issue where invoice periods were incorrectly calculated when subscriptions started on the 1st of a month and 'Align to Period Start' was enabled. The fix ensures invoices accurately reflect the subscription's billing cycle, displaying the correct month and dates. This prevents invoicing discrepancies and improves financial reporting.
Original PR description
Steps to reproduce: ------------------------------------- 1. Install the Subscription module. 2. Go to Subscription > Configuration > Recurring Plans. * Open a Monthly recurring plan and enable Align…
Steps to reproduce: ------------------------------------- 1. Install the Subscription module. 2. Go to Subscription > Configuration > Recurring Plans. * Open a Monthly recurring plan and enable Align to Period Start. 3. Create a new Subscription: * Select the configured monthly plan. * Add any subscription product. * In the Other Info tab, set a Start Date in the past on the 1st day of a month (e.g., 01/11/2025). 4. Confirm the subscription. 5. Create a draft invoice. Observation: ----------------------------------- In the invoice line, you see the message: `61 days 11/01/2025 to 12/31/2025` It should be: `1 Month 11/01/2025 to 11/30/2025` Issue: ----------------------------------- https://github.com/odoo/enterprise/blob/a5a76de5f25483afa5432ed333c48d78832f128c/sale_subscription/models/sale_order_line.py#L376-L378 In `_get_invoice_line_parameters`, the computation attempts to find the next 1st day of the month However, `new_period_stop` already includes the billing period. When `new_period_stop` is in the past, an extra month is added through `new_period_stop + relativedelta(months=1)`, resulting in an incorrect period range Solution: ----------------------------------- Use `new_period_start` as the anchor point for period computation. Ensure the billing period ends on the last day of the starting month when Align to Period Start is enabled For upsell orders, the fix is NOT applied because for upsells, `new_period_stop` is already set to the parent subscription's `next_invoice_date`, which represents the correct billing boundary. opw-5920036 Forward-Port-Of: odoo/enterprise#107407
This update corrects a flaw in how Odoo calculates the available capacity for appointments booked through Google Reserve. Previously, the system reserved the entire party size, leading to potential overbooking. The fix ensures accurate capacity allocation, preventing scheduling conflicts and improving the booking experience for users.
Original PR description
The current logic inside the appointment google reserve controller to compute reserved and used capacity per resource was incorrect. It was reserving the full party size for each resource instead of properly computing how much spots we are reserving for each. The code was fixed and a test was adapted for proper coverage. Task-6120016 Forward-Port-Of: odoo/enterprise#113908 Forward-Port-Of: odoo/enterprise#113805
This update ensures that transaction dates pulled from iap are always within the correct 'lock date' range. Previously, transactions could be retrieved with dates before the lock date, which was an error. Now, the system uses the maximum of the lock date and the last statement date to guarantee accurate data retrieval.
Original PR description
To fetch transactions from iap, we have to give a date from. Before this commit, it was possible to have a date from prior the lock date which is not supposed to happen. This commit will do the max between the lock date the last date of either the statement or the statement line. task-6019584 Forward-Port-Of: odoo/enterprise#110010
This update fixes an issue where the Envia integration for Colombia was incorrectly formatting zip codes. By using Envia's geocoding service, the system now accurately transmits the required municipality codes, ensuring correct delivery processing. This resolves a previous error that caused incorrect zip code formatting and potential delivery problems.
Original PR description
For Colombia, Envia expects the municipality/DANE-style code in the address payload, not the raw postal code. When `l10n_co_edi` was not installed, the Envia integration fell back to the partner zip code and padded it locally before sending it as both `postalCode` and `city`. This produced incorrect values such as turning the Ibagué zip code `730001` into `73000100`, while Envia geocodes resolves that zip code to `73001000`. Use Envia geocodes to resolve the Colombia zip fallback and retrieve the `stat_8digit` code expected by Envia instead of deriving it locally. opw-6083181 Forward-Port-Of: odoo/enterprise#112838
This update corrects a visual issue where clickable scorecards in the spreadsheet module were displaying a default arrow cursor instead of a pointer on hover. Now, scorecards that function as buttons in the dashboard view correctly show a pointer cursor when hovered over, improving user experience and clarity. This resolves a minor usability problem.
Original PR description
## Description of the issue/feature this PR addresses: Current behavior before PR: - The scorecard case was missed when replacing hasOdooMenu with hasOdooLink. - Clickable scorecards were showing the default arrow cursor instead of a pointer on hover. Desired behavior after PR is merged: - Scorecards now correctly use hasOdooLink to determine if they are clickable. - The pointer cursor is displayed on hover when the scorecard acts as a button in dashboard view. Task: [6116584](https://www.odoo.com/odoo/2328/tasks/6116584) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where the calculation of neutralized payroll amounts was inaccurate in the Swiss HR Payroll module. The fix ensures that payroll deductions are correctly processed, leading to more precise financial reporting and compliance with Swiss tax regulations. This improves the reliability of payroll data.
This update resolves an issue preventing users from generating session reports in the CO company setting. The fix addresses a technical problem with accessing sale details, ensuring the report generation process now functions correctly. This improves the usability of the POS system for CO companies.
Original PR description
Currently when trying to generate the session report a traceback appears. Steps to reproduce: ------------------- * Install l10n_co_edi_pos * Switch to CO company * Open pos session * Make a sale * Close register * Generate session report > Traceback Why the fix: ------------ We get the sale details with: https://github.com/odoo/odoo/blob/0ce5baf2918960591284eb494d82dfef07043af0/addons/point_of_sale/models/report_sale_details.py#L429-L430 Where the config ids given to `get_sale_details` are given here https://github.com/odoo/odoo/blob/0ce5baf2918960591284eb494d82dfef07043af0/addons/point_of_sale/models/report_sale_details.py#L413-L414 From there we can't access any field from a list of number. opw-6049484 Forward-Port-Of: odoo/enterprise#111627
This update resolves a bug where the state of a date field in forms was incorrectly being reset after saving. Specifically, closing the date picker would sometimes revert the date back to an older value. This issue has been fixed to ensure accurate date tracking and prevent data inconsistencies.
Original PR description
Step to reproduce: - Go on view form with a date field - Set the date with the input by typing the date with day and month (mm/dd or dd/mm), then press enter - Save the record - Redo the second step by with a different date - Save the record The assignation of the state.value done when closing the datepicker is useless and can put old a value in the state. The datepicker hasn't finished to update of the record that the assignation put back the old value of the record back in the state. The reason why it happens only after a save is still unknown. task-6095467 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258111
This update fixes an issue where Arabic text on invoices was incorrectly formatted in the generated PDF. The change ensures parentheses surrounding Arabic characters are positioned correctly, improving readability for invoices in English. This resolves a display problem for international invoices.
Original PR description
**Problem:** When printing an invoice in English (LTR report) with a product whose name contains Arabic text and parentheses (e.g., لوحة توزيع كهربائية 100 أمبير (شنايدر )), the brackets appear in…
**Problem:** When printing an invoice in English (LTR report) with a product whose name contains Arabic text and parentheses (e.g., لوحة توزيع كهربائية 100 أمبير (شنايدر )), the brackets appear in the wrong position in the generated PDF. **Steps to reproduce:** 1. Create a product named: لوحة توزيع كهربائية 100 أمبير (شنايدر ) 2. Create an invoice with that product 3. Print the invoice PDF in English 4. Observe the brackets are misplaced in the description column **Current behavior:** Parentheses appear detached from the Arabic word they enclose, floating at the wrong end of the text. **Expected behavior:** Parentheses correctly wrap the enclosed Arabic text. **Cause of the issue:** Odoo's report CSS sets `direction: ltr` on elements that are ancestors of the line description span. When CSS `direction: ltr` targets the same element as `dir="auto"`, wkhtmltopdf's WebKit engine lets the CSS rule win, keeping the paragraph base direction as LTR. The Unicode BiDi algorithm then resolves parentheses (neutral characters) using LTR as the base direction, misplacing them. **Fix:** Placing `dir="auto"` directly on the `<span>` that renders the line description — rather than the parent `<td>` — avoids the CSS override. wkhtmltopdf then detects the first strong character (Arabic) and uses RTL as the base direction for that span, allowing the BiDi algorithm to correctly position the brackets. opw-5884712 Forward-Port-Of: odoo/odoo#258521 Forward-Port-Of: odoo/odoo#251190
This update fixes a performance issue in the website's gradient picker. Previously, dragging the angle knob triggered excessive updates, causing lag. The fix now delays SCSS generation until the drag is complete, resulting in a smoother and faster editing experience.
Original PR description
Cause: ====== Because the debounce function is called with await, the execution of `debouncedSCSSColorsCusto` pauses for every mousemove event. This prevents subsequent calls from overlapping,…
Cause: ====== Because the debounce function is called with await, the execution of `debouncedSCSSColorsCusto` pauses for every mousemove event. This prevents subsequent calls from overlapping, meaning the debounce logic never triggers to cancel previous timers. This results in the heavy SCSS generation running sequentially for every single mouse movement, causing performance lag. In other words, the await forced the browser to handle one request at a time, completely finishing it before accepting the next one. Solution: ========== In the gradient picker, only update the visual CSS gradient preview during drag and defer the `onGradientChange` callback to mouseup to avoid triggering heavy operations (e.g. SCSS generation) on every mousemove. Steps to reproduce: =================== 1. Go to website & edit mode. 2. Click on Header block. 3. Click on background color preview & select Gradient & Custom. 4. Click and drag the Angle knob. => The website preview triggers excessive updates dragging the knob opw-5411628 Forward-Port-Of: odoo/odoo#241764
This update resolves an issue where published course cards with buttons in their descriptions were displaying a grey overlay. The fix accurately targets only unpublished courses, ensuring a consistent and correct visual presentation of all course cards on the website. This improves the user experience and visual consistency.
Original PR description
Steps to reproduce: ================= 1. Go to eLearning > Courses and create a published course 2. In the Description tab, add a button with a link and save 3. Go to /slides on the website 4. The…
Steps to reproduce: ================= 1. Go to eLearning > Courses and create a published course 2. In the Description tab, add a button with a link and save 3. Go to /slides on the website 4. The course card appears with a grey overlay (0.5 opacity) => Published course cards with a button in the description show a grey overlay => Only unpublished course cards should have the grey overlay Cause: ====== In [1], the opacity for unpublished courses was moved from `.o_wslides_course_unpublished` to its container using a `:has()` selector. However, the selector `div:has(> .card + .card-body, ...)` was too broad: it matched any container whose `.card` child had a sibling `.card-body`, regardless of whether the course was unpublished. When a course description contains a button (or any block-level element), the browser renders the button outside the `.card` element. This creates the structure `div > .card + .card-body` that the selector matches, applying a 0.5 opacity grey overlay to fully published courses. Solution: ======== The fix restricts the first selector arm to only match when `.o_wslides_course_unpublished` is the sibling, ensuring published courses with buttons in their descriptions are not affected. [1]: https://github.com/odoo/odoo/pull/249969 opw-5900287 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258700
6 changes
Enhancements to existing features
This update simplifies the generation of Spanish tax reports (303 and 347) by automatically displaying key fields. Specifically, the 'exonerated from 390' option is now available on the print wizard for recent periods, and a new grouping is added for auditing annual reports, streamlining the reporting process.
Original PR description
In this PR: - In tax report 303, the 'exonerated from 390' boolean field is now visible on the print BOE wizard , when period is either last month or last quarter so that user does not have to enable it manually on the AEAT page. - In the annual tax report 347, when a user clicks to audit the operations of the entity, a new group by is added in context to group the reports by move type and date(quarter). task-5863744 Forward-Port-Of: odoo/enterprise#113644 Forward-Port-Of: odoo/enterprise#108057
This update enhances the process of updating German Point of Sale (POS) certification orders by ensuring sequential updates through a new locking mechanism. Additionally, unnecessary UI validation for ZIP codes and addresses has been removed, streamlining the user experience. This improves order consistency and reduces complexity.
Original PR description
In this commit: ------------------- - We have added logic to execute API calls using a mutex for order updates (such as line updates and removals). This ensures that each update is processed (sequentially), allowing us to properly track and maintain order consistency. - We removed the ZIP and address validation on the UI since the backend already assigns default values if they are missing. So, there’s no need to restrict the user on the UI. task:5941742 Forward-Port-Of: odoo/enterprise#113809 Forward-Port-Of: odoo/enterprise#108694
Resolved issues and error corrections
This update resolves a technical problem within the AI composer patch that was causing crashes. The fix ensures the focus event is correctly passed to the base handler, maintaining stability and preventing errors when the AI composer is used. This improves the overall reliability of the AI composer functionality.
Original PR description
**Purpose of this PR:** The AI composer patch overrides `Composer.onFocusin()` but did not forward the focus event to the base handler. This used to be harmless while the base mail composer focus handler did not use the event. Since odoo/odoo#258974, the mail composer now uses the event to stop `focusin` propagation, so dropping it makes the base handler crash when AI composer focus is triggered. This commit fixes the AI composer patch by forwarding the focus event to the base handler, preserving the expected handler contract. Related: odoo/odoo#258974 Task-5954657 Forward-Port-Of: odoo/enterprise#113763
This update ensures that transaction data pulled from iap uses the correct date range. Previously, incorrect date ranges could occur, leading to inaccurate reporting. This fix now uses the latest statement or statement line date, guaranteeing accurate data retrieval.
Original PR description
To fetch transactions from iap, we have to give a date from. Before this commit, it was possible to have a date from prior the lock date which is not supposed to happen. This commit will do the max between the lock date the last date of either the statement or the statement line. task-6019584 Forward-Port-Of: odoo/enterprise#110010
This update resolves an issue preventing users from generating session reports in the CO company setting. The fix corrects a technical error related to accessing sale details, ensuring the report generation process now functions correctly. This improves the usability of the POS system for CO company users.
Original PR description
Currently when trying to generate the session report a traceback appears. Steps to reproduce: ------------------- * Install l10n_co_edi_pos * Switch to CO company * Open pos session * Make a sale * Close register * Generate session report > Traceback Why the fix: ------------ We get the sale details with: https://github.com/odoo/odoo/blob/0ce5baf2918960591284eb494d82dfef07043af0/addons/point_of_sale/models/report_sale_details.py#L429-L430 Where the config ids given to `get_sale_details` are given here https://github.com/odoo/odoo/blob/0ce5baf2918960591284eb494d82dfef07043af0/addons/point_of_sale/models/report_sale_details.py#L413-L414 From there we can't access any field from a list of number. opw-6049484 Forward-Port-Of: odoo/enterprise#111627
This update resolves an issue where the checkout process became unresponsive when using Avatax with Brazilian tax identification. The previous code was unnecessarily calling external tax APIs, leading to errors that blocked the confirmation step. This fix removes the unnecessary API call, improving checkout stability and performance.
Original PR description
Issue: --- The extra external_tax call introduced in odoo/enterprise#101579 is causing multiple issues: 1- It doesn't catch errors while `_get_and_set_external_taxes_on_eligible_records` easily raises errors, causing uncatch errors in `website_sale`. 2- Extra unnecessary external api call in non-express checkout methods which is not desirable. Steps to reproduce: --- 1- Install l10n_br_avatax_sale, website_sale 2- Using a public user, add a product to cart and got to checkout. 3- In the address form, use CPF identification type. Outcome: The confirm button is unresponsive. Cause: --- This is due to uncatch error raised by external tax call, while it was not necessary at this step of this flow to call external tax api. opw-6005767 Forward-Port-Of: odoo/enterprise#113861 Forward-Port-Of: odoo/enterprise#112515
14 changes
Resolved issues and error corrections
This update resolves an issue where Odoo invoices sent via Peppol were being rejected due to incorrect tax calculations. The fix ensures that the TaxableAmount is consistently calculated across all tax categories, including those with discounts and fractional prices, aligning with Peppol's requirements.
Original PR description
Steps to reproduce: 1. Create an invoice with a 0% tax (Exempt from VAT, category E) 2. Add two lines with 20% discount and fractional prices: - qty=4, price_unit=39.615 and qty=4 with…
Steps to reproduce: 1. Create an invoice with a 0% tax (Exempt from VAT, category E) 2. Add two lines with 20% discount and fractional prices: - qty=4, price_unit=39.615 and qty=4 with price_unit=0.84 3. Send via Peppol 4. Peppol rejects with: [BR-E-08] VAT category taxable amount shall equal the sum of Invoice line net amounts The TaxableAmount recalculation in _ubl_get_tax_subtotal_node was only applied for tax category 'S' (Standard Rate). However, Peppol schematron has identical rules for all tax categories: BR-E-08 (Exempt), BR-Z-08 (Zero), BR-AE-08 (Reverse Charge), etc. When lines have discounts and fractional prices, the individually rounded LineExtensionAmount values can sum to a different total than the tax base_amount. This affects both rounding modes. For 'S' taxes this was already handled, but for 'E' (and others) it caused Peppol rejection. Remove the 'S'-only filter and match dynamically against the actual tax category code so the recalculation applies universally. opw-6093243 Forward-Port-Of: odoo/odoo#258909
This update resolves an issue where a Peppol document would repeatedly be created when a user removed their journal configuration. The fix ensures that acknowledgements are correctly sent to IAP, preventing unnecessary document duplication and improving the reliability of Peppol document processing. This ensures accurate data exchange and avoids potential delays.
Original PR description
When a user removes its journal on its Peppol configuration, when receiving one, a new document would be created but the acknowledgement would never be sent to IAP. Everytime the user tries to retrieve new documents, the same document would then be created again. Forward-Port-Of: odoo/odoo#259330
This update resolves an issue where a new Peppol document was incorrectly created and repeatedly generated when a user removed their journal configuration. The fix ensures that acknowledgements are properly sent to IAP, preventing duplicate document creation and improving the reliability of the Peppol integration.
Original PR description
When a user removes its journal on its Peppol configuration, when receiving one, a new document would be created but the acknowledgement would never be sent to IAP. Everytime the user tries to retrieve new documents, the same document would then be created again. Forward-Port-Of: odoo/enterprise#113922
This update resolves an error that occurred when users tried to access ticket links after an attendee was removed from an event. The fix prevents a technical error (IndexError) by gracefully handling empty attendee lists, ensuring ticket links always work correctly.
Original PR description
Currently, an error occurs when accessing the ticket link after the related attendee has been deleted. **Steps to Reproduce:** - Install the **Events** module. - Create a new event. - Create an attendee with a valid email ID. - Make sure the email is sent successfully. - Delete the attendee for the event. - From the received email, try to click on the **"View Tickets"** link. **Error:** `IndexError - tuple index out of range` **Cause:** The controller filters registrations using the provided `registration_ids`, but when the attendee is deleted, the resulting recordset becomes empty. It raises an error when trying to access the first element of an empty recordset. **Fix:** This commit handles empty recordsets by returning early when no registrations are found. sentry-7357927405
This update fixes an issue where transaction date ranges were sometimes inaccurate when importing data from Codabox. The change ensures that the date range used for importing transactions is always the latest available date – either the Codabox lock date or the last statement date – preventing data discrepancies.
Original PR description
To fetch transactions from iap, we have to give a date from. Before this commit, it was possible to have a date from prior the lock date which is not supposed to happen. This commit will do the max between the lock date the last date of either the statement or the statement line. task-6019584 Forward-Port-Of: odoo/enterprise#110010
This update simplifies the process of reloading your chart of accounts. Previously, a confusing error message prompted users to update the localization app. Now, a clear warning directs users directly to the relevant apps, making the process easier and more intuitive.
Original PR description
Previously, when new taxes with new tax tags were introduced, reloading the chart of accounts would raise a generic UserError suggesting to update the localization app. This could be confusing for users, as it did not indicate which app needed to be updated. With this commit, the UserError is replaced by a RedirectWarning that guides users directly to the Apps menu with the relevant localization modules, making the resolution clearer and more user-friendly. Forward-Port-Of: odoo/odoo#259398 Forward-Port-Of: odoo/odoo#257515
This update fixes an issue where tax group changes could cause errors due to account updates not being synchronized. The change ensures that account relationships within tax groups are only updated when necessary, preventing constraint violations and improving system stability. This primarily impacts how tax groups are managed and related to accounts.
Original PR description
Upon chart reload, accounts will not be updated (except for tax_ids), but tax groups are. If a tax group was changed to relate to a different account and this account was re-purposed (e.g.…
Upon chart reload, accounts will not be updated (except for tax_ids), but tax groups are. If a tax group was changed to relate to a different account and this account was re-purposed (e.g. account_type changed from an incompatible to a compatible type, the fact that the account is not updated will trigger constraints in the tax group when it is written. IOW, if the purpose of an account is not changed, its use should not be changed either. E.g.: 1f4710deb206736cd71580d8fd95552d9b7c8014 changed the value of `tax_payable_account_id` on tax group `tax_group_cofins_incl_goods` to `account_template_202011005` and the same commit changed the value of `account_type` on `account_template_202011005` from `liability_non_current` to `liability_payable`, triggering `_constrains_payable_receivable_account` (in 19.2: https://github.com/odoo/odoo/blob/e00dd21880c3c4e5c22d65567c700e02541f7259/addons/account/models/account_tax.py#L68). So here, we skip the update of relations to accounts on tax groups, if the account already exists. Forward-Port-Of: odoo/odoo#259160
This update resolves a technical issue that prevented demo flows from running correctly when new Peppol and Nemhandel response data was added. The team corrected a missing key in the demo utility files, ensuring demo mode now functions without errors. This improves the reliability of our demo environment.
Original PR description
With the recent addition of responses in Peppol and Nemhandel, we forgot to adapt the mocking data for demo flows, which resulted in tracebacks in demo mode. Forward-Port-Of: odoo/odoo#258655
This update fixes an issue where floors were incorrectly displayed in the restaurant's point-of-sale system. Previously, floors were loaded through indirect processes, leading to inaccurate floor selections. Now, the system correctly uses the configured floor IDs for each POS configuration, ensuring accurate floor selection for restaurant orders.
Original PR description
Floors loaded indirectly (e.g. via recursive loading of paid orders) could appear in the floor selector even if they belonged to a different PoS config. The selector was iterating over the full in-memory model store instead of the floors explicitly assigned to the current config. opw-6025172 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258178 Forward-Port-Of: odoo/odoo#257113
This update resolves an issue preventing users from generating session reports in the CO company setting. The fix addresses a technical error related to accessing sale details, ensuring the report generation process now functions correctly. This improves the usability of the POS system for CO companies.
Original PR description
Currently when trying to generate the session report a traceback appears. Steps to reproduce: ------------------- * Install l10n_co_edi_pos * Switch to CO company * Open pos session * Make a sale * Close register * Generate session report > Traceback Why the fix: ------------ We get the sale details with: https://github.com/odoo/odoo/blob/0ce5baf2918960591284eb494d82dfef07043af0/addons/point_of_sale/models/report_sale_details.py#L429-L430 Where the config ids given to `get_sale_details` are given here https://github.com/odoo/odoo/blob/0ce5baf2918960591284eb494d82dfef07043af0/addons/point_of_sale/models/report_sale_details.py#L413-L414 From there we can't access any field from a list of number. opw-6049484 Forward-Port-Of: odoo/enterprise#111627
This update removes a confusing tooltip from the calendar popover for boolean fields. The tooltip was displaying unnecessary HTML content, creating a poor user experience. This change simplifies the calendar interface and improves usability.
Original PR description
Before this commit, the tooltip of a boolean field in calendar popover shows html content when the user hovers the boolean field. This commit removes the tooltip of boolean field in calendar popover since the information inside that tooltip is not really useful for the user. Issue found during the development of task-5994205 Forward-Port-Of: odoo/odoo#259069 Forward-Port-Of: odoo/odoo#259011
This update resolves an issue where images on the website weren't displaying correctly on deeper pages. The fix adds missing forward slashes to image source URLs, ensuring the browser correctly interprets them. This ensures all website images, including those on product pages, display properly.
Original PR description
This commit fixes two missing leading slashes in the "src" attribute of two "img" tags in `s_cta_mockups`. The browser resolves links differently based on leading slashes. Before this commit, the lack of leading slahses caused the snippet to not display properly on deeper pages (for example, "/shop/product-name"). task-6103616 Forward-Port-Of: odoo/odoo#258879
This update resolves an issue where the Avatax integration in the express checkout process was causing the confirmation button to become unresponsive. The fix removes unnecessary external API calls related to tax calculations, streamlining the checkout flow and improving stability. This change addresses a bug related to error handling during tax calculations.
Original PR description
Issue: --- The extra external_tax call introduced in odoo/enterprise#101579 is causing multiple issues: 1- It doesn't catch errors while `_get_and_set_external_taxes_on_eligible_records` easily raises errors, causing uncatch errors in `website_sale`. 2- Extra unnecessary external api call in non-express checkout methods which is not desirable. Steps to reproduce: --- 1- Install l10n_br_avatax_sale, website_sale 2- Using a public user, add a product to cart and got to checkout. 3- In the address form, use CPF identification type. Outcome: The confirm button is unresponsive. Cause: --- This is due to uncatch error raised by external tax call, while it was not necessary at this step of this flow to call external tax api. opw-6005767 Forward-Port-Of: odoo/odoo#259229 Forward-Port-Of: odoo/odoo#256692
This update resolves an issue where the checkout process became unresponsive when using the Avatax module with the Brazilian localization. The previous code was unnecessarily calling external tax APIs, leading to errors and preventing users from completing their purchases. This fix removes the unnecessary API calls, restoring the checkout functionality.
Original PR description
Issue: --- The extra external_tax call introduced in odoo/enterprise#101579 is causing multiple issues: 1- It doesn't catch errors while `_get_and_set_external_taxes_on_eligible_records` easily raises errors, causing uncatch errors in `website_sale`. 2- Extra unnecessary external api call in non-express checkout methods which is not desirable. Steps to reproduce: --- 1- Install l10n_br_avatax_sale, website_sale 2- Using a public user, add a product to cart and got to checkout. 3- In the address form, use CPF identification type. Outcome: The confirm button is unresponsive. Cause: --- This is due to uncatch error raised by external tax call, while it was not necessary at this step of this flow to call external tax api. opw-6005767 Forward-Port-Of: odoo/enterprise#113861 Forward-Port-Of: odoo/enterprise#112515
2 changes
Resolved issues and error corrections
This update resolves an issue where barcode quantities were displayed with slight rounding errors due to how JavaScript handles decimal numbers. The fix ensures accurate quantity representation in the barcode interface, preventing discrepancies in inventory tracking. This improves data reliability for warehouse operations.
Original PR description
**Steps to reproduce:** * Install `stock` module. * Go to Settings and enable: * Storage Locations (Warehouse). * Batch, Wave & Cluster Transfers. * Create a Product and set its on-hand quantity to…
**Steps to reproduce:**
* Install `stock` module.
* Go to Settings and enable:
* Storage Locations (Warehouse).
* Batch, Wave & Cluster Transfers.
* Create a Product and set its on-hand quantity to 60.
* Go to Inventory → Configuration → Operation Types and create a new operation type:
* Set Type of Operation to Internal Transfer.
* In the Barcode App tab, enable Group batch lines.
* Go to Inventory → Operations → Internal Transfers and create a new transfer:
* Select the newly created Operation Type.
* Add the created Product with quantity 4.4.
* Mark the transfer as To Do.
* Create another Internal Transfer with the same configuration:
* Select the same Operation Type.
* Add the same Product with quantity 48.8.
* Mark the transfer as To Do.
* Open the Internal Transfers list view.
* Select both created transfers.
* Click Action → Add to Wave Transfer.
* Choose A new Wave Transfer and confirm.
* In the popup, select both transfers and add them to the wave.
* Open the Barcode application.
* Open the created operation and select the Batch on the right side
to open the wave transfer in the barcode interface.
**Observed behavior:**
- The grouped line quantity is displayed as 53.99999996 instead of
the expected value(53.2).
**Cause:**
- When the Barcode app loads data,` _createState()` is executed,
which calls `groupLines()`.
- Inside this method, quantities are aggregated using standard
JavaScript floating-point addition:
https://github.com/odoo/enterprise/blob/08d0a7f480046bb489ca69e7b3535e99cb20eee5/stock_barcode_picking_batch/static/src/models/barcode_picking_batch_model.js#L204-L205
- Since JavaScript stores numbers as binary floating-point values,
decimals like 4.4 and 48.8 cannot be represented exactly.
Repeated additions accumulate precision errors, producing results
like 53.99999996 instead of 53.2.
**Fix:**
- Aggregate quantities using `formatFloat` with the barcode precision
before converting them back to floats
- `formatFloat` rounds the value according to the configured precision
of the barcode model, ensuring the intermediate result is normalized
after each addition. Converting the formatted value back with
`parseFloat` guarantees the stored number respects the expected
decimal precision and prevents floating-point accumulation errors.
---
opw-5932329
Forward-Port-Of: odoo/enterprise#110241This update resolves a recurring problem where a new Peppol document was incorrectly created when a user removed their journal configuration. Previously, acknowledgements weren't sent, leading to duplicate document creation. This fix ensures proper acknowledgement transmission, streamlining Peppol document processing.
Original PR description
When a user removes its journal on its Peppol configuration, when receiving one, a new document would be created but the acknowledgement would never be sent to IAP. Everytime the user tries to retrieve new documents, the same document would then be created again. Forward-Port-Of: odoo/enterprise#113922
30 changes
New functionality added to Odoo
This update introduces core functionality for complying with Belgian Joint Committee 302 (CP302) regulations within our payroll system. It includes features like seniority calculations, premium payments for overtime, and specific wage reductions for students and work clothes, ensuring accurate and compliant payroll processing for Belgian employees.
This update adds integration with the ZKTeco BioTime attendance system, automatically syncing employee attendance records. The system prioritizes matching new check-ins with existing attendance data and flags any unmatched transactions for HR review. Old attendance records are automatically deleted after 30 days.
Original PR description
Add integration with ZKTeco BioTime attendance system. Introduce two new models: - zkteco.terminal: represents physical attendance devices synced from the BioTime server - zkteco.transactions: stores raw punch records fetched via the BioTime API and processes them into hr.attendance records Check-out transactions are matched in priority order: 1. Existing open attendance (no check-out) within a configurable lookback period (default 2 days) 2. A check-in from the current processing batch (FIFO) 3. If no match is found, the transaction is left unprocessed and an activity is created for the HR manager to review Processed transaction records are automatically cleaned up after 30 days. Task-4521436
Enhancements to existing features
This update improves the Social Balance Sheet report by adding key data points like overtime and streamlining the report's structure. The changes also include updated translations for French, Dutch, and German, ensuring accurate reporting across multiple languages. This enhancement provides more comprehensive financial data for business analysis.
This update improves the Gantt view by displaying progress bars for all employees, regardless of whether they have scheduled leave. Previously, the Gantt only showed progress for employees with leaves. This enhancement provides a more complete and accurate view of employee work hours.
Original PR description
…hose without leaves Previously, the gantt view only showed the progress bars (the number of worked hours) for employees who had leaves. Now, this PR shows the progress bars for all employees, even those without leaves. Task-5999717
This update enhances the self-order point-of-sale system by adding a country prefix selector for phone numbers. This simplifies the process for customers entering their contact information, improving the user experience and reducing potential errors. The change aligns with recent community updates for a consistent user flow.
Original PR description
In this commit we adapt a tour such that it follows the changes done in the corresponding community commit. Task: 5913205
This update simplifies the holiday scheduling view within the Enterprise module. The outdated custom popover has been replaced with the standard dialog used in other views, creating a more consistent and user-friendly experience. This change improves usability for HR staff managing employee time off.
Original PR description
- removed the custom popover for the timeoff gantt view and replaced it with the same dialog that appears in other views task-id: 5473334
This update enhances the reliability of tests within Odoo's enterprise modules by ensuring consistent handling of company environments. The changes address a limitation where simply specifying the company wasn't enough to filter tests correctly, leading to inconsistent results. This improves the overall stability and accuracy of the testing process.
Original PR description
More information on the related community commits.
This update clarifies the capacity settings within the appointment scheduling feature. The changes involve updating labels for both users and resources, making the system easier to understand and use. Additionally, a minor simplification was made to the timezone settings, improving code efficiency.
Original PR description
This commit improves and clarifies the capacity feature on the form view of the appointment type model by changing some labels for both users and resources. Also takes the opportunity to simplify the syntax of the timezone setting in the controller by removing unnecessary code. task-5173341
This update introduces a system to track payrun closing dates specifically for different employee types within the payroll system. The system now provides a warning to users when payrun closing dates are not set for particular employee types, ensuring accurate payroll processing and compliance. This improves payroll management and reduces potential errors.
Original PR description
In this commit, we added a payroll_closing_date for the employee type model. We added a warning to notify the user when the payrun closing date for that employee type. task-5922782
This update allows users to add rentable products directly to sales orders, automatically converting them into rental orders. To revert to a standard sales order, users must remove the rental dates. This simplifies the process of managing rental products within sales transactions.
Original PR description
Before this commit, rentable products could only be added to rental orders. This makes sense because the sales price of a rentable product is actually the rental price. Adding a rentable product to a standard sales order would undervalue the product. For example, a bike rented for $100/week should not be sold for $100, but rather $1000. After this commit, adding a rentable product to a sales order automatically converts it to a rental order. To convert a rental order back to a sales order, users must remove both the start and return rental dates. task-6003684
This update enhances the Discuss interface by displaying phone call status icons, providing a clearer picture of user availability. It automatically tracks active calls and prioritizes leave status when the HR Holidays module is enabled, ensuring accurate presence information. This improves communication and coordination.
Original PR description
Display phone status icons in Discuss when a user is on a call. Compute phone_* IM status on active calls and notify presence updates. Ensure leave status keeps precedence when hr_holidays is installed. community PR: https://github.com/odoo/odoo/pull/254136 task-5478885
This update aligns the self-order POS tour with recent community changes, streamlining the user experience. It involves adapting the delivery distance calculation to ensure accurate estimations for self-order transactions, enhancing the overall functionality of the POS system.
Original PR description
In this commit we adapt a tour such that it follows the changes done in the corresponding community commit. Task: 4177086
Resolved issues and error corrections
This pull request corrects a minor typo in the Odoo Enterprise settings related to company information for several payroll localizations (BE, IN, LT, LU, MA). The change ensures consistent and accurate wording within the application, improving the user experience. This fix addresses a visual inconsistency that could have caused confusion.
Original PR description
To reproduce the issue: 1. Install either BE,IN,LT,LU,MA payroll localization 2. Open settings view 3. "Offical Company Information" Should be "Official Company Information"
This update ensures the 'Load Order' button remains hidden across all screen sizes for Grab/GoFood orders. Previously, resizing the window would briefly show this button, which was replaced with 'Set Food Ready' to prevent manual order changes. This change improves the user experience and data integrity for these orders.
Original PR description
For Grab/GoFood orders, the "Load Order" button is replaced by "Set Food Ready" to prevent manual edits. Previously, resizing or minimizing the window caused the hidden "Load Order" button to reappear due to responsive layout overrides (e.g., mobile view CSS classes). This commit updates the visibility logic to ensure the button remains strictly hidden across all screen sizes for external delivery orders. opw-6044176 Forward-Port-Of: odoo/enterprise#111222
This update fixes an issue where appointment bookings were incorrectly reserving full party sizes for resources. The change ensures that resources are accurately allocated, preventing overbooking and improving the scheduling process. A new test has been added to verify the fix.
Original PR description
The current logic inside the appointment google reserve controller to compute reserved and used capacity per resource was incorrect. It was reserving the full party size for each resource instead of properly computing how much spots we are reserving for each. The code was fixed and a test was adapted for proper coverage. Task-6120016 Forward-Port-Of: odoo/enterprise#113908 Forward-Port-Of: odoo/enterprise#113805
This update ensures that transaction dates used to fetch data from iap are always within the correct 'lock date' range. Previously, dates could be inaccurate, leading to potential data discrepancies. This fix guarantees the most reliable and accurate retrieval of financial information.
Original PR description
To fetch transactions from iap, we have to give a date from. Before this commit, it was possible to have a date from prior the lock date which is not supposed to happen. This commit will do the max between the lock date the last date of either the statement or the statement line. task-6019584 Forward-Port-Of: odoo/enterprise#110010
This update resolves an issue where the 'Time Off Type' dropdown was empty when creating time off entries via the Gantt view. The fix ensures the dropdown correctly displays available time off types by properly filtering the database search. This improves the usability of the time off management feature.
Original PR description
**Steps to Reproduce:**
1. Open Time Off App->Management->Time Off->Gantt View
2. Highlight multiple dates/cells to trigger the multi-create popover, then click "Set".
3. Open the "Time Off Type" dropdown.
Result: The dropdown is completely empty.
**Bug Cause:**
The Gantt multi-create popover skips `_loadNewRecord`, meaning `work_entry_type_filter_domain` never computes and evaluates to an empty list. This hardcodes `('id', 'in', [])` into the search, forcing the database to return 0 records.
**Solution:**
Remove the broken computed `('id', 'in', [])` domain from the `work_entry_type_id` field in `hr_leave_gantt_multi_create_view`. Add the `context="{'gantt_multi_create_company_filter': True}"` flag to the field to trigger the country-filtering logic implemented in the `_search` method.
**Task:** 6109569This update corrects a technical issue impacting Envia delivery in Colombia. Previously, the system incorrectly formatted zip codes, leading to inaccurate data sent to Envia. Now, the system uses Envia's geocoding to ensure correct data formatting, improving delivery reliability and reducing potential delays.
Original PR description
For Colombia, Envia expects the municipality/DANE-style code in the address payload, not the raw postal code. When `l10n_co_edi` was not installed, the Envia integration fell back to the partner zip code and padded it locally before sending it as both `postalCode` and `city`. This produced incorrect values such as turning the Ibagué zip code `730001` into `73000100`, while Envia geocodes resolves that zip code to `73001000`. Use Envia geocodes to resolve the Colombia zip fallback and retrieve the `stat_8digit` code expected by Envia instead of deriving it locally. opw-6083181 Forward-Port-Of: odoo/enterprise#112838
This update resolves an issue preventing the generation of the session report in the CO company setting. The fix addresses a technical problem with accessing sale details, ensuring users can now successfully generate and utilize this important report. This improves the functionality of the point-of-sale system.
Original PR description
Currently when trying to generate the session report a traceback appears. Steps to reproduce: ------------------- * Install l10n_co_edi_pos * Switch to CO company * Open pos session * Make a sale * Close register * Generate session report > Traceback Why the fix: ------------ We get the sale details with: https://github.com/odoo/odoo/blob/0ce5baf2918960591284eb494d82dfef07043af0/addons/point_of_sale/models/report_sale_details.py#L429-L430 Where the config ids given to `get_sale_details` are given here https://github.com/odoo/odoo/blob/0ce5baf2918960591284eb494d82dfef07043af0/addons/point_of_sale/models/report_sale_details.py#L413-L414 From there we can't access any field from a list of number. opw-6049484 Forward-Port-Of: odoo/enterprise#111627
This update resolves an issue where the system was incorrectly retrieving neutralization data for payroll calculations in Switzerland. The fix ensures accurate payroll processing by correcting the way the system fetches this critical information. This improves the reliability of financial reporting related to employee compensation.
Original PR description
Forward-Port-Of: odoo/enterprise#113961
This update resolves a test failure in the WhatsApp module related to how archived user IM statuses are handled. The test case was incorrectly designed, failing because the partner wasn't linked to a user. The fix ensures the test accurately reflects the system's behavior by properly linking the partner to a user.
Original PR description
Purpose of this PR: compute_im_status returns false when main_user_id is not set. The testcase was failing because the partner was not linked to a user. Updated the testcase by linking the partner to a user to match the expected behavior. task-4797343
This update ensures that waiting payslips (draft payslips with calculated amounts) are automatically recalculated whenever employee information or payroll settings are modified. This guarantees that the payslip data remains accurate and reflects the latest changes, improving payroll reporting reliability. This change addresses a potential discrepancy between the payslip and the underlying data.
Original PR description
This commit makes waiting payslips recomputes whenever inputs are changed to make sure the sheet is up to date with inputs -waiting payslip: a payslip in draft with computed lines Task#5439146
This update resolves a potential issue where timesheet rules could cause access errors due to mismatched company restrictions on linked projects. By adding a company ID to the timesheet rule, we ensure that projects linked to the rule adhere to the same company, preventing these access problems and improving user experience.
Original PR description
This commit's purpose is to prevent potential access rigths error with aw.rule. Currently it is possible to set a project/task that is restricted to a specific company to an aw.rule. This can lead to a user using that aw.rule having access rights error because he does not have access to that project. To fix this issue, we add a company_id to the aw.rule model and ensure that the project/task linked to it follow the same company as the aw.rule it is set on task-6116548
This update fixes a bug where changes to embedding settings caused sources to incorrectly show as 'processing'. The fix ensures that updates are properly processed and sources are updated correctly, preventing delays and inaccurate status displays. This improves the reliability of the AI embedding feature.
Original PR description
### Issue: In ai.agent, any update to any field causes the sources to be shown as processing. ### Fix In `ai.agent.write()`, the provider change detection was comparing the provider object directly against the stored provider name string. Also, `_cron_generate_embedding` returned early when no missing embeddings were found, skipping the `_update_sources_status` call and leaving sources stuck in processing status. task-id-6121579
This update corrects a technical issue that was preventing users from properly accessing returns reports. The change ensures that the reporting module functions correctly after a recent update to the main account kanban view. This resolves a traceback error and maintains the reliability of the returns reporting process.
Original PR description
After a recent IMP in account return kanban view in #113292 , the overall styling of kanban view was improved, but the inherited view in this module was unchanged which caused traceback. This commit fixes that issue.
This update addresses a crash that occurred when users cleared the 'Today' date filter or selected 'All time' in the global filters. The fix ensures the system remains stable and prevents unexpected errors, improving the user experience. This resolves a technical issue impacting spreadsheet edition functionality.
Original PR description
traceback when deleting the current value of a date filter Task: [6019061](https://www.odoo.com/odoo/2328/tasks/6019061)
This update enhances the Sign module's user experience by streamlining request workflows and addressing key usability issues. Specifically, users can now cancel sent signature requests and receive prompts to update contact information, while a critical bug causing issues with the 'Thank You' dialog has been resolved.
Original PR description
This commit introduces several UX improvements, workflow adjustments, and bug fixes to the Sign module to streamline the user experience. Specific changes: - Views & UI: - Add a related model filter to the sign templates search view. - Clean up the sign request pivot view by removing irrelevant measures. - Request Management: - Allow the original request sender to cancel a sent signature request. - Stop automatically saving the certificate of completion into the Documents app. - Integrate the missing-email popover into the Send Sign Request wizard to prompt users to update contacts on the fly. - Bug Fixes: - [FIX] Resolve the dismiss bug in the Thank You dialog by properly hooking the ESC key/background click into the global dialog environment.
Code cleanup and technical improvements
This update standardizes how date ranges are handled in Odoo's Enterprise module's user interfaces. Previously, relative filters (like 'last week' or 'last month') were implemented inconsistently, leading to errors. This change ensures correct date filtering when users select date ranges, resolving a previous 'Invalid Daterange' issue and improving the overall user experience.
Original PR description
Currently, preset relative filter in view architectures (last week, last month ...) are all written differently. Sometimes they include today, sometimes not, some used 7d + 1d ... We rewrite them to be compatible with the smart dates. WHY: When oponing these arch filter in the filter dialog, we now have the correct smart date instead of `Invalid Daterange` Community PR: odoo/odoo#252484 task#5959944
This update streamlines how work entries are tracked by removing a redundant selection field. It replaces it with a simple boolean flag, making the system more efficient and easier to manage. This change improves the accuracy of time-based calculations related to attendance and schedules.
Original PR description
As of now, the work_entry_source field is a Selection field that is defined in hr_work_entry with only 1 option (Time Off) and then overridden in hr_work_entry_attendance to add another option…
As of now, the work_entry_source field is a Selection field that is defined in hr_work_entry with only 1 option (Time Off) and then overridden in hr_work_entry_attendance to add another option (Attendance). This doesn't make sense anymore, because: 1) Time Off is always considered, that option makes it so that the time is based on the working schedule. 2) There are at most 2 options, so it doesn't need to be a selection. For these reasons we remove the field and substitute it with a Boolean field attendance_based. This field will be defined in hr_work_entry_attendance and, since in the code work_entry_source was sometimes referenced even without the attendance module installed, we change those references to instead use a function result. In other words, anything in hr_work_entry_attendance or that depends on it can directly use the attendance_based field, while if we need to use code that is not dependant on it, we instead call a new _get_work_entry_source function that by defualt returns 'calendar' (the name of the Time Off option in the selection, but is then overridden in hr_work_entry_attendance to return 'attendance' if the attendance_based field is checked. Task: 6050497 Community PR: https://github.com/odoo/odoo/pull/254900
This update changes how tracking information is stored in email messages, resulting in significant space savings and faster loading times. By storing tracking data directly within the message body, the system avoids complex database queries and reduces code complexity, leading to improved performance and a simplified development process.
Original PR description
RATIONALE Independent study [1] recently showed that storing tracking values takes quite some db space for few "real usage". Storing tracking values directly in body html is therefore considered as…
RATIONALE
Independent study [1] recently showed that storing tracking values takes
quite some db space for few "real usage". Storing tracking values directly
in body html is therefore considered as an alternative to using a table with
fields holding field ID, information, old and new values in a structured
and easy-to-manipulate way.
According to the study author [2], advantages are
* up to 30% db space saved;
* faster read when chatter is loaded as we can remove queries required to
access tracking value table, as well as field-based group check that
ensure security at field level;
* faster write (which globally never happen in real life use cases);
* globally faster update due to not having index on tracking table to
update;
* easier search, allowing to search words in body instead of having to
search in body + in field_id / old_value / new_value of tracking
value model;
* less custom code for audit trail, which does simple html formatting
based on tracking values;
* less custom code for formatting. Having directly html allows to remove
code that fetches tracking values (protected model), formats it and send
it to frontend JS chatter, which in turn has to define a model and
formatting for those;
Disadvantages that should not be considered as disadvantages are
* no more field-based security. It is known since tracking introduction
that field with group should not be tracked [3];
* loss of translation support: search on translated field names for
example is not possible, as field name is stored translated. However
this is not considered as an issue, because you generally search on
values (content) which is often language independent. Translated values
search was not correctly supported with tracking values (e.g. selection
fields), and this is not going to be improved with html. We could have
improved tracking value translation support but it was not considered
as being worth it;
* potential loss of protection against update. Previously tracking values
were not accessible to anyone (except admins), unless going through
dedicated methods or controllers. Now being able to update body means
being able to update tracking values inside it. Protection can be added
but checking pre- and post- content of html fields is notoriously fragile
and more easily bypassed. This was not considered as a real issue even
for audit trail;
Although original study author explains that tracking value were never used
in Odoo, it is also worth pointing out that removing tracking value model
leads to several changes in various addons:
* duration mixin rewrite. This mixin computes time spend in stages for
heavy production models like crm.lead, project.task, helpdesk.ticket,
hr.applicant. It was previously computed based on tracking values, aka
no extra db usage. We now have to store this time information as
retrieving it in html is not really scalable. This means a new ever
growing fields on those models, storing time information in json.
* project burndownchart rewrite. It was also based on tracking values
and therefore needs a complete rewrite.
* mrp.production requires a new stored field to find the last start
production date, previously fetched (without performance issue
being reported) in tracking values;
* hr.leave.allocation requires a new stored field to store allocation
change for accrual, previously fetched (without performance issue
being reported) in tracking values;
* hr.recruitment.report rewrite, as it was based on tracking values and
now uses stored duration mixin values;
* tracking values were also used for sale.order log and tracking but
"time issues" lead to rewrite them as a custom model instead of
tracking values a few years ago (without clear insights on what
was really the issue, original author of this change being the same
as the one requesting removal of tracking values);
Other authors [4] tend to disagree with the study author, pointing out that
* people actually track fields with groups -> this may lead to security
issues, or having to stop tracking those fields. Study author discards
this usage, considered as advanced / too niche;
* having to store duration information, allocation details, mrp production
date, ... is going to negatively impacts db storage gains. Study author
considers those are negligible without providing any numerical
value;
* storing html means no easy chatter reformat, as well as useless noise
stored in db (html nodes, class names, ...). Study author points out
that his study shows at least 30% gain whatever the situation;
* easier leak of tracked values: each person having access to the
message has access to body, hence tracking values. Previously tracking
values were never accessible (except admins), only given through
dedicated controllers or methods (e.g. discuss store);
* tracking values are used in production environment notably when
analyzing issues (e.g. previous state of records, ...), having a stored
structured way of finding information is valuable in this case. Doing
same analysis in html is going to be harder, especially with non
translated field names, parsing html, ...
* gained db space is anyway negligible compared to a full production
db (e.g. optimistic estimated 50 Gb for a 3 Tb on odoo.com). This is
anyway going to be erased by ever-growing size of db (accumulated
messages, activities, ...);
All this taken into account it was decided by R&D head to move to html
usage for tracking values, given the numerous advantages it gives. However
in order to still allow advanced usage of tracking values, a now optional
module holds the mail.tracking.value table and records creation when
performing tracking. With that module feature should globally be equivalent
(minus the field-level groups security support) for advanced / technical
usage.
DETAILS
Please also refer to community commits.
**Commit 1: helpdesk: store stage durations according to company working hours**
-------
This commit updates helpdesk ticket stage durations based on the company’s
working hours. We now store the total working hours in duration_tracking,
which is used for ticket sla frozen hours instead of the tracking model.
Example: a ticket stays in a stage for 2 days. Previously, it recorded 24
hours, but now it stores 16 hours based on working hours.
This duration is used in sla policies, so there is no longer a need to
manually exclude non-working hours.
**Commit 2: hr_recruitment_reports: refactor recruitment stage analysis report**
--------
Use stage duration to determine how long an applicant stays in each stage
which was previously based on the tracking model.
hr_recruitment_stage_report: convert the report to use the duration_tracking
format. start and end dates are now computed based on the time spent in each
stage.
**Commit 3: account_followup, hr_payroll, helpdesk_stock: clean tracking & groups on fields**
-----
- Remove groups from fields to avoid restricting tracked values
- Add missing tracking=None where needed
**Commit 4: l10n_us_hr_payroll: store allocation data changes**
-----
Previously to this commit accrual is computed based on tracking values linked
to 'number_of_days' field previously to the requested date. As we are
migrating away from stored tracking values we now store dedicated
information on allocation itself.
New field is a JSON holding date-based changes. Overall computation and
behavior should stay the same as before.
REFERENCES
Also see odoo/odoo#248505 (and linked PRs) for preliminary work cleaning and
improving tracking mechanism.
Task-5260614
[1] cannot disclose it but it might come from a bigram who wants to remove
that table since (at least) 2017 and prefers to have each addon doing
some kind of custom tracking instead of a transversal approach;
[2] see 1;
[3] :shrug:
[4] globally most of R&D senior developers as depicted in January and February
internal guru meetings;
Co-Authored-By: Prakash Prajapati <ppr@odoo.com>
Co-Authored-By: Jigar Vaghela <jva@odoo.com>
Co-Authored-By: Fabien Pinckaers <fp@odoo.com>
Co-Authored-By: Thibault Delavallee <tde@odoo.com>8 changes
Enhancements to existing features
This update simplifies the generation of Spanish tax reports (303 and 347) by automatically displaying key fields. Specifically, the 'exonerated from 390' field is now visible on the print BOE wizard for relevant periods, and a new grouping is added for audit operations in report 347, streamlining the reporting process.
Original PR description
In this PR: - In tax report 303, the 'exonerated from 390' boolean field is now visible on the print BOE wizard , when period is either last month or last quarter so that user does not have to enable it manually on the AEAT page. - In the annual tax report 347, when a user clicks to audit the operations of the entity, a new group by is added in context to group the reports by move type and date(quarter). task-5863744 Forward-Port-Of: odoo/enterprise#113644 Forward-Port-Of: odoo/enterprise#108057
This update enhances the process of updating German Point of Sale certification transactions by ensuring order updates are processed sequentially. Additionally, unnecessary ZIP and address validation checks on the user interface have been removed, streamlining the user experience. This change improves order consistency and reduces complexity.
Original PR description
In this commit: ------------------- - We have added logic to execute API calls using a mutex for order updates (such as line updates and removals). This ensures that each update is processed (sequentially), allowing us to properly track and maintain order consistency. - We removed the ZIP and address validation on the UI since the backend already assigns default values if they are missing. So, there’s no need to restrict the user on the UI. task:5941742 Forward-Port-Of: odoo/enterprise#113809 Forward-Port-Of: odoo/enterprise#108694
Resolved issues and error corrections
This update resolves an issue where lunchtime shifts were incorrectly calculated when an employee's time zone differed from the calendar time zone. The fix ensures accurate lunch time tracking and corrects the reset of work entries when time zone discrepancies exist, improving the reliability of employee time data.
Original PR description
- Correct lunch time shift if employee tz differs from calendar tz - Correct reset of WE if employee tz differs from calendar tz Task: 6072325
This update resolves a critical issue in the payroll processing for Mexico that could cause the system to crash when no bank account information was available for an employee. The change ensures the system handles missing data gracefully, preventing errors and maintaining accurate payroll calculations. This improves stability and data integrity.
Original PR description
Accessing the employee bank accounts using index [0] raised an IndexError when no accounts were defined. Additionally, computing the CLABE flag using len() caused a TypeError when the account number was missing. This change uses a safe recordset slice to avoid accessing empty records and guards the length check to only evaluate when a value is present. It prevents crashes while keeping the original behavior unchanged and avoids sending invalid empty values in the CFDI.
This update ensures that transaction dates pulled from Codabox are always within the correct timeframe. Previously, incorrect date ranges could occur, but this fix now uses the latest statement or statement line date, guaranteeing accurate reporting. This improves the reliability of financial data.
Original PR description
To fetch transactions from iap, we have to give a date from. Before this commit, it was possible to have a date from prior the lock date which is not supposed to happen. This commit will do the max between the lock date the last date of either the statement or the statement line. task-6019584 Forward-Port-Of: odoo/enterprise#110010
This update fixes an error in how Odoo calculates the available capacity for appointments booked through Google Reserve. Previously, the system reserved the full party size for each resource, leading to overbooking. This change ensures accurate capacity allocation, preventing scheduling conflicts and improving appointment management.
Original PR description
The current logic inside the appointment google reserve controller to compute reserved and used capacity per resource was incorrect. It was reserving the full party size for each resource instead of properly computing how much spots we are reserving for each. The code was fixed and a test was adapted for proper coverage. Task-6120016 Forward-Port-Of: odoo/enterprise#113908 Forward-Port-Of: odoo/enterprise#113805
This update resolves an issue preventing the generation of session reports in the CO company setting. Previously, generating the report would result in an error. The fix corrects a data access problem, allowing users to successfully generate and review their POS session reports.
Original PR description
Currently when trying to generate the session report a traceback appears. Steps to reproduce: ------------------- * Install l10n_co_edi_pos * Switch to CO company * Open pos session * Make a sale * Close register * Generate session report > Traceback Why the fix: ------------ We get the sale details with: https://github.com/odoo/odoo/blob/0ce5baf2918960591284eb494d82dfef07043af0/addons/point_of_sale/models/report_sale_details.py#L429-L430 Where the config ids given to `get_sale_details` are given here https://github.com/odoo/odoo/blob/0ce5baf2918960591284eb494d82dfef07043af0/addons/point_of_sale/models/report_sale_details.py#L413-L414 From there we can't access any field from a list of number. opw-6049484 Forward-Port-Of: odoo/enterprise#111627
This update resolves an issue where the 'Create a Payslip' button was unresponsive when no payslips existed in the W2 report. The fix corrects a technical error in the system's code that prevented the button from functioning properly. This ensures users can consistently generate W2 reports.
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#111735
1 change
Resolved issues and error corrections
This update ensures that raw component moves in manufacturing orders consume the correct quantities of materials. Previously, the system incorrectly added all available stock to the production, even when manually adjusting quantities on the move line. This fix now prioritizes the quantities specified on the move line, ensuring accurate material consumption and reducing potential overstocking issues.
Original PR description
Commit https://github.com/odoo-dev/odoo/commit/63e44737fe469ab56b8e8e96c1ad47205ead1094 force `picked` to `True` when editing the stock move line in mrp module. The issue is, having Manufacturing installed, writing on any stock move (even in a picking) will go throughout this code and mark the move as picked. This commit adds a contrains to only update raw component moves. 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
1 change
Resolved issues and error corrections
This update resolves a test failure related to the calculation of holiday pay for Belgian employees. The fix removes tracking from a specific field, ensuring it's only computed when needed and preventing incorrect initial values from being set. This ensures accurate holiday pay calculations moving forward.
Original PR description
…ield The computed, non-stored field `l10n_be_holiday_pay_recovered_n1` had tracking enabled. When writing to any field on the employee, the `write` method calls `_track_prepare` for tracked fields if `mail_notrack` is not set in the context. `_track_prepare` reads the current value of tracked fields to store initial values. Because `l10n_be_holiday_pay_recovered_n1` is non-stored with no dependencies, this triggered a computation at the very beginning of the test, before payslips existed. Later, when payslips were created, the field was never recomputed, causing incorrect values and test failures. Previously, the `tracking_disable` context prevented early computation. The fix removes the tracking attribute entirely, so the field is only computed when accessed, avoiding premature reads and fixing the tests. task: 6095445