Daily updates from Odoo
Tuesday, April 28, 2026
81 changes · saas-19.3
Resolved issues and error corrections
This update ensures the o_spreadsheet component used within Odoo 19.3 is running the latest version. This improves the functionality and stability of the spreadsheet feature, which is used for various reporting and data management tasks. The update was developed by a team of Odoo engineers.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/be0ca17fdc [REL] 19.3.0 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This update fixes a technical issue that caused a traceback error when viewing restaurant bookings with no bookings scheduled. The problem stemmed from an automatic change introduced during a migration, which incorrectly targeted a variable. This commit corrects the variable access, ensuring the booking list displays correctly even when empty.
Original PR description
Inside the custom list renderer for booking for pos_restaurant we access `this.list.records` which doesn't exist and throws a traceback when no there are no bookings. The `this.` was added automatically by a migration script for OWL3 to force this usage to target component variables. But in this case `list` is set inside the web.ListRenderer template with `t-set`. This commit will revert the automatic change for the access to and replace `this.list.records`, with `list.records` Task-[6147678](https://www.odoo.com/odoo/project/1737/tasks/6147678)
This update corrects a technical issue related to how binary data is handled within the l10n_uk_reports_cis module. A recent change in Odoo required a specific format ('BinaryBytes') for binary fields, which was previously causing errors. This fix ensures the module functions correctly and avoids data processing problems.
Original PR description
Since https://github.com/odoo/odoo/pull/244421, binary field does not accept 'bytes' but to be wrapped explicitly as 'BinaryBytes' task-5481774
This update resolves a problem where activity updates weren't reliably shared between tabs in Odoo. The issue stemmed from interference with a specific internal route (`/mail/data`) during testing. This fix ensures that activity updates are consistently reflected across all relevant tabs, improving user experience.
Original PR description
The `@mail/activity/activity/activity updates are shared between tabs` fails in a non-deterministic fashion. It occurs because the `/mail/data` route can interfere with the test. runbot-242616 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#260862 Forward-Port-Of: odoo/odoo#260265
This update ensures consistent test tagging across Odoo versions 18 and 19, preventing disruptions to the nightly test suite. Previously, an error during test parsing could lead to the entire suite being disabled. This change backports a key fix to ensure reliable test execution.
Original PR description
When an error is parsed during the nightly, the default test tag is not correct in 18 and 19, what could lead to disabling the complete hoot suite if not taking enough care when disabling a test. This backports part of #234937 to ensure with have the correct tag in all version supporting hoot tests. Forward-Port-Of: odoo/odoo#261618 Forward-Port-Of: odoo/odoo#261526
This update ensures that the unit of measure (UoM) specified for a supplier's information related to a specific product variant remains consistent across all other variants of the same product. Previously, this could lead to inconsistencies in pricing and ordering. This fix improves data accuracy and reduces potential errors in purchase order processing.
Original PR description
Make sure any UoM defined on a supplierinfo having a specific variant cannot be used by other variant of the same product template Task: 6042382 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#260490 Forward-Port-Of: odoo/odoo#259213
This update corrects a warning message that incorrectly flagged transactions using the Cash Basis accounting method as having an inactive Construction Industry Scheme. The fix ensures that CABA entries are properly excluded from this check, preventing unnecessary alerts and streamlining reporting. This improves the accuracy of CIS-related data.
Original PR description
Currently, journal entries may be flagged for the CIS inactive partner check, causing unnecessary warning. Steps to reproduce: - Install l10n_uk_reports_cis. - Accounting > Configuration > Settings, enable "Cash Basis" - Open "20% CIS" Purchase tax - Set "Tax Exigibility" to "Based on Payment" and add a Cash Basis Transition Account - Set Outstanding account on the Bank journal - Create a partner and enable (Accounting tab) Construction Industry Scheme" - Create a vendor bill for this partner with a the 20% CIS tax - Register payment to the Bank journal - Open the created CABA entry Issue: Warning will be shown "Construction Industry Scheme hasn't been enabled for this vendor." Analysis: The warning flag is incorrectly triggered because the CABA entry has `invoice_line_ids` field set. However entries should be excluded by this check as it should only apply to purchase-related documents. opw-5942603 Forward-Port-Of: odoo/enterprise#113003
A minor bug preventing the generation of EC sales returns was resolved. This issue stemmed from a typographical error introduced during a recent update to the ec sales list report. This fix ensures accurate reporting of returned sales transactions.
Original PR description
With the rework of the ec sales list report(https://github.com/odoo/enterprise/commit/4096c1fcbd7f31f70153058d2e3f9eab6d82e356#diff-2f90e40d6e7b35681a4af03037e8e5ee0fddab2ba0876d9f148bf79786a91c29), the return generation of this type became generic but a small bug appeared. It was not generating anymore because of a typo. Forward-Port-Of: odoo/enterprise#114815
This update fixes an issue where the BIK (Business Income Key) calculation for company cars wasn't accurately reflecting changes throughout the month. The system now correctly updates the BIK monthly based on the employee's car usage, ensuring accurate payroll calculations and compliance. This impacts the accuracy of employee compensation related to company car usage.
Original PR description
**Description of the issue/feature this PR addresses:** When there is a change of car during a month, the employee will have 2 versions but all will be merged on the same payslips but currently only the BIK of one version is taken into account (or no BIK if the employee has no company car anymore) **Current behavior before PR:** . car_atn value equal the yearly_atn / 12 . ATN.CAR rule returns the car_atn value of the first version **Desired behavior after PR is merged:** . Update the car_atn value to be computed monthly, based on the number of calendar days in the current month . Update ATN.CAR payslip rule, it get the value of the car's atn on the current payslip month then prorated based on the versions periods within the payslip period . Modify the corresponding tests . Add corresponding tests task-6108696 Forward-Port-Of: odoo/enterprise#113484
This update ensures that adding a new car or bike automatically makes all vehicles of the same type available in the system. Previously, adding a new vehicle could incorrectly make vehicles of a different type visible. This change maintains consistent vehicle availability for better reporting and management.
Original PR description
When you are getting a new car or a new bike, it'll make available all the your vehicle whatever is the type of vechicle. To keep consistent behaviour, we are only make available vahicle of same type Bug introduced in refactoring: https://github.com/odoo/odoo/pull/220160 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261002
This update corrects a rounding error that occurred when creating kit products. Previously, the system wasn't properly distributing the cost of components within a kit, leading to inaccurate purchase order values. This fix ensures accurate cost calculations for kit products, resolving potential discrepancies in valuation.
Original PR description
### Steps to reproduce: - Create a kit product with 6 bom lines (with a `cost_share` of `0.0%`) - Create + confirm a purchase order for 1 unit of the kit product at 60 - Validate the delivery #### >…
### Steps to reproduce: - Create a kit product with 6 bom lines (with a `cost_share` of `0.0%`) - Create + confirm a purchase order for 1 unit of the kit product at 60 - Validate the delivery #### > 6 layers were created with values 9.99, 10, 10, 10, 10 and 10 There are two issues with purchased kit valuation addressed in this PR: ### Issue 1: Since 8c199f7783527735b35c9fbda334cbdcd55a004f, the product price unit is not supposed to be rounded anymore. However, kit products rely on the rounded `cost_share` field of the `mrp.bom.line` to determine which part of the price of the kit product is handled by which component: https://github.com/odoo/odoo/blob/591102ff37fef1f0b9a946fee3f9d85789653e65/addons/mrp/models/stock_move.py#L245-L246 https://github.com/odoo/odoo/blob/591102ff37fef1f0b9a946fee3f9d85789653e65/addons/purchase_mrp/models/stock_move.py#L28 https://github.com/odoo/odoo/blob/591102ff37fef1f0b9a946fee3f9d85789653e65/addons/purchase_mrp/models/stock_move.py#L38 This leads to inevitable rounding issues where `60/6` does not match `10`: https://github.com/odoo/odoo/blob/591102ff37fef1f0b9a946fee3f9d85789653e65/addons/purchase_mrp/tests/test_purchase_mrp_flow.py#L1273-L1275 simply because 1/6 is represented as `16.67%` and not by `16.66666666666666%`. However, values such as 1/6 can be obtained if you do not set any `cost_share`, since the kit explosion will equidistribute its cost share: https://github.com/odoo/odoo/blob/591102ff37fef1f0b9a946fee3f9d85789653e65/addons/purchase_mrp/models/mrp_bom.py#L42-L48 ### Fix of this issue: We set the digits to `False` for stability reason as the columns have been initiallised as "numeric" values and needs to stay numeric: https://github.com/odoo/odoo/blob/b007b0a4f7e56f6dc44df3154e13745c9981eae3/odoo/fields.py#L1627-L1650 Note that when the digit is Falsy on the field, the field value is formatted to the second digit by the front end: https://github.com/odoo/odoo/blob/3542c542eac5b204e69a8dd6ae1907cfcef60af3/addons/web/static/src/views/fields/float/float_field.js#L58-L76 https://github.com/odoo/odoo/blob/12e453302a950df4d9ee45954f54bdf610888eda/addons/web/static/src/core/utils/numbers.js#L214-L227 In particular, when we create the bom and set the `cost_share`, all possible values will be rounded to the second decimal just as before. This change will therefore only alter the rounding behavior in the DB for equidistributed values such as `16.66666666666666%`. ### Issue 2: While the value of the kit product is exploded and distributed among components, the values of each individual `stock.valuation.layer` are themselves rounded before creation based on the company currency: https://github.com/odoo/odoo/blob/4188436a9e800b062bf9f3b0055cad86acc47e19/addons/stock_account/models/product.py#L240-L255 https://github.com/odoo/odoo/blob/4188436a9e800b062bf9f3b0055cad86acc47e19/addons/stock_account/models/stock_valuation_layer.py#L30 Now, this is problematic since the sum of the values of the layers is expected to match the total value of the purchase order line (that is, the non-rounded value of the components of the purchased kit). ### Fix of this issue: We compute and distribute the rounding error among layers corresponding to the purchased kit product before creation (since layer values are not expected to be modified afterwards), based on the non-rounded computation, since this value should now be exact (as the unit cost is not rounded anymore). opw-5085457 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258124 Forward-Port-Of: odoo/odoo#252034
This update resolves an issue where invoice settlement could fail if the commercial partner information wasn't fully loaded. The fix now directly uses the partner ID from the invoice data, streamlining the process and preventing errors. This ensures smoother invoice settlement operations.
Original PR description
Before this commit, it was possible that commercial_partner_id was not loaded, which caused an error when settling an invoice. This commit fixes the issue by avoiding the need to load the full partner record. Since only the partner ID is required to load the account move, it is now read directly from the raw data, which already includes the ID. opw-6023150 Forward-Port-Of: odoo/enterprise#114110 Forward-Port-Of: odoo/enterprise#111957
This update corrects a minor issue where payslips were incorrectly marked as 'paid' during report generation for the ISO20022 payroll accounting module. This ensures that reports accurately reflect the status of payroll transactions, improving data reliability for financial reporting. The change was a simple fix to prevent an unintended action during the report generation process.
Original PR description
…t generation Forward-Port-Of: odoo/enterprise#115273
This pull request corrects a minor typo within the marketing automation test suite. The fix ensures the tests run smoothly and accurately, maintaining the quality and reliability of the marketing automation functionality. This is an internal technical update.
Original PR description
Forward-Port-Of: odoo/enterprise#115315
This update fixes an issue where the 'Hide lines at 0' feature was removing the report-level total line from reports like the Trial Balance when printed. This commit ensures that total lines, including those without a parent, are always displayed, improving report accuracy and clarity for users. This change was implemented to maintain consistent and complete reporting.
Original PR description
When "Hide lines at 0" is enabled, printing e.g. the Trial Balance will drop the report-level "Total" line when printing. This commit fixes that. The issue was introduced in this commit[^1], which didn't consider total lines without a parent (i.e. root total lines). [^1]: https://github.com/odoo/enterprise/commit/7fec18b99eb2aa5ebc357dcad5f95f234db5b7d8 Forward-Port-Of: odoo/enterprise#115011 Forward-Port-Of: odoo/enterprise#114084
This update fixes a bug that prevented links within 'Button' snippets added to the website builder from being translated. Previously, these links were excluded from the translation process. Now, dropped button links are correctly tagged for translation, ensuring all website content can be localized.
Original PR description
Before this commit, links on `Button` inner snippets dropped from the sidebar (not through powerbox) were never translatable. `o_translate_inline` was only added in link insert flows or when already present in snippet template, not when dropping inner button snippets. As a result, dropped button anchors were missing `o_translate_inline` and were filtered out from translatable inline links. Steps to reproduce: - Enter edit mode. - Drag and drop a `Button` inner snippet. - Save. - Switch to translation mode. - Try to edit the button link: it cannot be edited. This commit adds handling on snippet drop to tag dropped anchors with `o_translate_inline`. task-5943645 Forward-Port-Of: odoo/odoo#261433 Forward-Port-Of: odoo/odoo#249019
This update resolves an issue preventing AI chat functionality on Safari devices. The fix addresses a compatibility problem with older Safari versions that don't fully support a key streaming technology. By switching to a manual reader loop, the AI chat now works reliably on Safari, ensuring a smooth user experience.
Original PR description
Steps: - Install ai - Open ai chat - Try to send a message - Traceback The AI chat was failing on iOS with a traceback when trying to process the stream response. Even though MDN suggests…
Steps: - Install ai - Open ai chat - Try to send a message - Traceback The AI chat was failing on iOS with a traceback when trying to process the stream response. Even though MDN suggests compatibility, Safari (WebKit) versions prior to 26.4 do not implement the AsyncIterator protocol on ReadableStream. This makes `for await (const chunk of response.body)` throw a TypeError as `[Symbol.asyncIterator]` is undefined. https://developer.mozilla.org/en-US/docs/Web/API/ReadableStream This commit replaces the async iteration with a manual reader loop (`getReader().read()`). This is the low-level primitive supported by all versions of Safari and ensures the stream is properly consumed and unlocked even if the connection is interrupted. Steps to reproduce: 1. Open Discuss/AI Chat on an iPad or iPhone (eg. 26.4). 2. Send a message. 3. The response triggers a JS error. ```js Uncaught Promise > undefined is not a function (near '...chunk of asyncStream...') ``` opw-6054307 Forward-Port-Of: odoo/enterprise#113926
This update resolves an issue preventing portal users from creating tickets via email when automatic assignment is enabled. The fix ensures the system correctly accesses employee calendars across companies, eliminating access errors and restoring ticket creation functionality. This improves the portal's usability for users and streamlines the ticket submission process.
Original PR description
Problem: Portal email with auto-assignment crashes ticket creation due to calendar access. When a helpdesk ticket is created via email from a portal user and automatic assignment is enabled, the…
Problem: Portal email with auto-assignment crashes ticket creation due to calendar access. When a helpdesk ticket is created via email from a portal user and automatic assignment is enabled, the system computes working intervals for users to determine assignment. This computation goes into resource logic, where resource.calendar fields (flexible_hours) are read. If the assigned user is linked to multiple employees across companies, multiple resource.resource records are evaluated. The helpdesk email flow starts in sudo, but the employee calendar lookup explicitly drops sudo before returning the calendar. Then, the calendar is accessed in the portal context, which does not have permission to read the other company's resource.calendar, leading to an AccessError and preventing ticket creation. Although the failure is triggered from Enterprise helpdesk, the actual crash occurs in Odoo (resource.calendar), meaning the fix must be applied there. Fix: Preserve sudo when fetching employee calendars to ensure that scheduling logic does not depend on the access rights of the email sender. A test is added in helpdesk_holidays, as the issue requires both helpdesk (auto-assignment) and hr (employees/resources) to reproduce. The test simulates a portal email flow with a multi-company user linked to multiple employees and ensures ticket creation succeeds. Steps to Reproduce: 1. Install Helpdesk, Employees, and enable multi-company 2. Create two companies (e.g., Company A and Company B) 3. Create one internal user (User X) with access to both companies 4. Create two employees linked to the same user: - Employee 1 in Company A - Employee 2 in Company B Make sure they are set with a start date, but no end date. Needs to be active employee. 5. Create a Helpdesk team in Company A 6. Add Agent X as a team member 7. Enable automatic assignment 8. Configure an email alias for the helpdesk team 9. Create a portal user 10. Send an email from the portal user to the alias Related Ticket: opw-6035099 Forward-Port-Of: odoo/odoo#261156 Forward-Port-Of: odoo/odoo#257720
This update resolves an issue where portal email auto-assignment would fail due to permission problems accessing employee calendars across different companies. The fix ensures the system uses the correct security context when accessing calendar data, allowing ticket creation to proceed smoothly. This improves the reliability of the helpdesk system for portal users.
Original PR description
Problem: Portal email with auto-assignment crashes ticket creation due to calendar access. When a helpdesk ticket is created via email from a portal user and automatic assignment is enabled, the…
Problem: Portal email with auto-assignment crashes ticket creation due to calendar access. When a helpdesk ticket is created via email from a portal user and automatic assignment is enabled, the system computes working intervals for users to determine assignment. This computation goes into resource logic, where resource.calendar fields (flexible_hours) are read. If the assigned user is linked to multiple employees across companies, multiple resource.resource records are evaluated. The helpdesk email flow starts in sudo, but the employee calendar lookup explicitly drops sudo before returning the calendar. Then, the calendar is accessed in the portal context, which does not have permission to read the other company's resource.calendar, leading to an AccessError and preventing ticket creation. Although the failure is triggered from Enterprise helpdesk, the actual crash occurs in Odoo (resource.calendar), meaning the fix must be applied there. Fix: Preserve sudo when fetching employee calendars to ensure that scheduling logic does not depend on the access rights of the email sender. A test is added in helpdesk_holidays, as the issue requires both helpdesk (auto-assignment) and hr (employees/resources) to reproduce. The test simulates a portal email flow with a multi-company user linked to multiple employees and ensures ticket creation succeeds. Steps to Reproduce: 1. Install Helpdesk, Employees, and enable multi-company 2. Create two companies (e.g., Company A and Company B) 3. Create one internal user (User X) with access to both companies 4. Create two employees linked to the same user: - Employee 1 in Company A - Employee 2 in Company B Make sure they are set with a start date, but no end date. Needs to be active employee. 5. Create a Helpdesk team in Company A 6. Add Agent X as a team member 7. Enable automatic assignment 8. Configure an email alias for the helpdesk team 9. Create a portal user 10. Send an email from the portal user to the alias Related Ticket: opw-6035099 Forward-Port-Of: odoo/enterprise#114986 Forward-Port-Of: odoo/enterprise#113047
This update resolves an issue where repeatedly deleting images in an Image Wall snippet caused a technical error (traceback). The fix adds a check to ensure the element still exists in the webpage before attempting to delete it, preventing the error and ensuring smooth operation.
Original PR description
Error: Cannot read properties of null (reading 'children') Steps to reproduce: 1.Go to Website -> Edit mode. 2.Add an Image Wall snippet. 3.Click on an image, then repeatedly click the Delete button. 4.Traceback occurs. Before this commit: The first delete click correctly removes the target element from the DOM, including its parent. On subsequent rapid clicks, the handler runs again on the same already-removed element. At that point, parentElement is null, so accessing children throws a traceback. After this commit: Added a safety check using `isConnected` in the delete handler to ensure the element is still part of the DOM. If not, the handler returns early. Repeated delete clicks no longer cause a traceback. task-6033622 Forward-Port-Of: odoo/odoo#261341 Forward-Port-Of: odoo/odoo#255733
This update ensures that the Slovak VAT tax reports generated by Odoo comply with the official Slovak XML format. Specifically, it enforces the required 2 decimal place precision for editable tax report cells, aligning with the latest VAT XSD schema. This improves data accuracy and avoids potential issues with VAT reporting.
Original PR description
As per the Slovak VAT XSD schema, editable fields must use a precision of 2 decimal places. So updating here to ensure compliance with the official XML format. Reference: https://ekr.financnasprava.sk/Formulare/XSD/dph2025.xsd Forward-Port-Of: odoo/odoo#261459
This change corrects a bug where archived email templates were incorrectly displayed in the applicant refusal wizard. The fix ensures that only active email templates are suggested, preventing confusion and ensuring accurate email communication during the application refusal process. This improves the user experience and data consistency.
Original PR description
Pre-requisites: --------------- 1. Create or duplicate any `hr.applicant` email template. 2. Archive the newly created template. 3. Archive the email template linked to a refuse reason. Steps to…
Pre-requisites: --------------- 1. Create or duplicate any `hr.applicant` email template. 2. Archive the newly created template. 3. Archive the email template linked to a refuse reason. Steps to reproduce: ------------------------- 1. Install hr_recruitment. 4. Go to Recruitment > Applications > All Applications and open an applicant. 5. Click on the "Refuse" button to open the refuse wizard. 6. Click on the "Email Template" and click on 'Search More' 7. Observe available templates Issue: ------- If a refuse reason is linked to an archived email template, the wizard automatically pre-fills that archived template Cause: ---------- The `_compute_template_id` method automatically assigns the template from the refuse reason without checking whether the template is active, which allows archived templates to be pre-filled in the wizard. https://github.com/odoo/odoo/blob/aa2a7c0e5a5de970cdb8f6a7ba9f02ad75cf5078/addons/hr_recruitment/wizard/applicant_refuse_reason.py#L91-L96 Solution: ----------- - Update `_compute_template_id` to ensure only active templates are automatically assigned. opw-5974244 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260853 Forward-Port-Of: odoo/odoo#251186
This update corrects a bug where the Gantt view incorrectly displayed maximum hours for employees with flexible work schedules. The fix ensures accurate hour calculations across all schedules, providing a clearer view of employee time tracking. This improves reporting and scheduling accuracy for flexible employees.
Original PR description
For employees having a `resource_calendar_id` with `flexible_hours`, the max hours displayed in the gantt view were incorrectly `days * hours_per_day`. This fixes it by taking the most relevant data between `days * hours_per_day`, `weeks * hours_per_week`, both, or nothing if the range is more than a month. The new calculation is `(weeks * hours_per_week) + min((days * hours_per_day), (hours_per_week))` task 5075953 Forward-Port-Of: odoo/enterprise#114661 Forward-Port-Of: odoo/enterprise#105266
This update changes the email address used for automated IAP communications from iap@odoo.com to noreply@odoo.com. This change improves email deliverability and reduces the likelihood of incorrect responses to automated messages from Odoo.
Original PR description
The current mail address is iap@odoo.com so some client respond to the automatic mail. This fix change it to noreply@odoo.com Task-6086556 Forward-Port-Of: odoo/odoo#260794 Forward-Port-Of: odoo/odoo#259691
This change updates the email address used for automated support notifications from iap@odoo.com to noreply@odoo.com. This improves email deliverability and reduces the risk of clients responding to outdated support addresses.
Original PR description
The current mail address is iap@odoo.com so some client respond to the automatic mail. This fix change it to noreply@odoo.com Task-6086556 Forward-Port-Of: odoo/enterprise#114712 Forward-Port-Of: odoo/enterprise#114097
This update ensures that replacement invoices generated from cancelled invoices accurately display the original invoice's source information (Sales Order reference). Previously, the 'Source' field was missing, hindering traceability. This fix maintains accurate record-keeping and compliance with reporting requirements.
Original PR description
### Issue before this commit: The "Source" (origin) field was missing from the PDF of replacement invoices. While the original invoice correctly displayed the Sales Order reference, the new invoice…
### Issue before this commit: The "Source" (origin) field was missing from the PDF of replacement invoices. While the original invoice correctly displayed the Sales Order reference, the new invoice generated through the request cancel process had an empty origin field. ### Steps to reproduce the issue: 1. Download Sales and l10n_mx 2. Set a UNSPSC Category for one product 3. Go to Sales, create a new Quotation and confirm it 4. Create invoice, confirm and send & print 5. Request cancel button -> create replacement invoice 6. In the new invoice there is no source origin invoice ### Cause of the issue: The invoice_origin field is defined with copy=False. Since the replacement logic uses the copy_data method without explicitly passing the origin value, the field was automatically cleared during the creation of the new invoice. ### Reason to introduce the fix: To ensure document traceability, the fix explicitly passes the invoice_origin from the original invoice to the replacement. This maintains the link to the Sales Order in the database and ensures the "Source" label appears on the printed PDF. opw-6070016 Forward-Port-Of: odoo/enterprise#114099
This update fixes an issue where the 'Configuration' menu was hidden for users with 'All Timesheets' access, preventing them from managing billing targets. The fix ensures that menu visibility updates correctly after changes to billing settings, providing consistent access for all approvers. It addresses a caching problem that caused delays in menu updates.
Original PR description
Steps to reproduce Bug 1: 1. Login as a user with "All Timesheets" (Approver) access. 2. Disable the "Timesheet Assistant" feature for this user. 3. Ensure "Billing Rate Indicators" is enabled in…
Steps to reproduce Bug 1:
1. Login as a user with "All Timesheets" (Approver) access.
2. Disable the "Timesheet Assistant" feature for this user.
3. Ensure "Billing Rate Indicators" is enabled in settings.
Steps to reproduce Bug 2:
1. Login as a user with "All Timesheets" (Approver) access.
2. Disable the "Billing Rate Indicators" setting in company settings.
3. Ensure "Timesheet Assistant" is enabled in settings.
Steps to reproduce Bug 3:
1. Only install 'sale_timesheet_enterprise'.
2. Go to Timesheets > Configuration > Settings.
3. Toggle "Billing Rate Indicators" (timesheet_show_rates) or change the encoding unit (timesheet_encode_uom_id), then save and check the menus.
Issue:
1. The "Configuration" menu is hidden, preventing access to billing targets even if the user has "All Timesheets" access.
2. The "Billing Time Targets" menu is still visible inside Configuration even if the "Billing Rate Indicators" feature is disabled in the settings.
3. Menu visibility does not update immediately after saving the settings. Menus that should appear (e.g., "Employee Billing Time Targets" or "Timesheets Assistant") remain hidden, or vice versa, until the cache is cleared or the server is restarted.
Cause:
1. The `hr_timesheet_enterprise_menu_configuration` was restricted in XML to groups that excluded "All Timesheets" users.
2. The `_load_menus_blacklist` logic in Python only blacklisted billing menus for users who were both Managers and System Admins, leaving them visible to regular Approvers even when the feature was disabled.
3. The load_menus method is decorated with @ormcache and stored in the Registry LRU cache. Menu visibility depends on timesheet_show_rates and timesheet_encode_uom_id through _load_menus_blacklist. When this field is updated, the ORM does not automatically invalidate the cached load_menus result because these specific fields are not part of the configuration fields. As a result, the stale old menu remains in memory.
Fix:
- Updated XML to include `hr_timesheet.group_hr_timesheet_approver` in the Enterprise Configuration menu permissions.
- Refactored `_load_menus_blacklist` to:
- Hide all billing-related menus for all users when the feature is disabled.
- Hide the parent Configuration menu if it would otherwise be empty.
- Override the write method in res.company in both modules and explicitly call env.registry.clear_cache() when the relevant configuration fields are modified.
task-5428010
Forward-Port-Of: odoo/enterprise#106464This update removes inactive reports from appearing in search results, enhancing the user experience. It also resolves a minor bug impacting VAT Return reports for Czech customers, ensuring accurate reporting. This improves the reliability of the reporting system.
Original PR description
When searching for reports through the search panel inactive reports still show up in the result, this change hide the inactive variant reports from the search result. Also, fixes a minor bug related the l10n_cz, When search for VAT Return (CZ) it would cause a bug due to missing the target report to look into. task: 6149101
This update fixes several issues in the SA Electronic Data Interchange (EDI) workflow for invoices. Specifically, buttons were incorrectly displayed for draft invoices, and validation errors weren't consistently shown. The changes ensure that buttons are only visible when appropriate and that validation alerts accurately reflect data requirements, improving the reliability of the EDI process.
Original PR description
Post-merge of the sending refactor, several unintended behaviors were identified in the SA EDI flow: - "Retry", "Process" and "Blocking Invoice" buttons remained visible even when invoice in draft state, which is inconsistent with the expected state flow. - Validations in the send wizard were not triggering uniformly; specifically, the ZATCA Reasons error was not appearing when it should. - Danger validation alerts for the Customer Reference were appearing even when field was correctly filled. This commit addresses these issues by: - Updating the view to hide "Retry", "Process" and "Blocking Invoice" buttons while in the Draft state. - Update validation conditions to show relevant errors in the send wizard and prevent unnecessary danger alerts. task-6149746
A recent update caused crashes when viewing customer previews linked to signed Field Service worksheets. This fix corrects a misapplication of a previous patch that was incorrectly converting signature data. By removing unnecessary base64 encoding, the customer preview now functions correctly.
Original PR description
Steps to reproduce: - 1. Install 'planning_field_service_worksheet'. 2. Open a Field Service planning slot, pick a worksheet template that has a signature property, and sign it. 3. From the slot, open the customer preview (portal page). Issue: - The customer preview crashes with a traceback. Cause: - Commit https://github.com/odoo-dev/enterprise/commit/b6997ed6f9a8fc29233e1d324e91bbda7eae4df2 added .to_base64() on prop['value'] to follow the same pattern as: https://github.com/odoo-dev/odoo/commit/c62d1cec96498f424c42aee87b1428a4615d576c , which fixed real Binary/Image fields that returns BinaryValue objects. That patch was misapplied here. The signature value in this template does not come from a Binary field, it comes from a Properties field, so signature data is already stored as a base64 encoded str. Fix: - Drop the .to_base64() call and embed prop['value'] directly, since it is already a base64 string. task-6157798
This pull request reverts recent cosmetic updates to the Mercado Pago payment module. These changes were previously introduced and are now being rolled back to maintain the stability and consistency of the payment processing system. This ensures a reliable experience for our users.
Original PR description
Revert the cosmetic changes that I introduced in commit 48709bb7be4b008b4f890577be06b64bb559d486 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures vehicle license plates are included in invoice exports when the enterprise 'account_accountant_fleet' module is used. It also corrects a bug related to tax calculations within the 'hr_expense' module, preventing incorrect repartition line splitting. This improves data accuracy and consistency for invoicing.
Original PR description
[FIX] account_fleet,hr_expense: vehicle sent in XML when an invoice line has a vehicle linked, the vehicle license plate will be in the export XML file only if the enterprise module `account_accountant_fleet` is installed. Any community db will then not have the ref included This commit moves the vehicle data in `account_fleet` to expose it to community dbs Also fix a bug when expense is installed: super was not called in a method about tax lines, causing side effects (splitting repartition lines when it shouldn't) runbot-242562
This update ensures that vehicle license plates are included in the invoice export XML file when the Enterprise module (`account_accountant_fleet`) is active. Previously, community databases lacked this information. Additionally, a bug causing incorrect tax line splitting has been resolved, improving data accuracy.
Original PR description
[FIX] account_accountant_fleet: vehicle sent in XML when an invoice line has a vehicle linked, the vehicle license plate will be in the export XML file only if the enterprise module `account_accountant_fleet` is installed. Any community db will then not have the ref included This commit moves the vehicle data in `account_fleet` to expose it to community dbs Also fix a bug when expense is installed: super was not called in a method about tax lines, causing side effects (splitting repartition lines when it shouldn't) runbot-242562
This update resolves an issue where the 'is_company' field calculation was not correctly reflecting company status in several Latin American localizations (AR, BR, EC). The change ensures accurate identification of companies, improving the reliability of business processes within these regions. This fix enhances data consistency and functionality for users in these markets.
Original PR description
*: l10n_{ar,br,ec}
In 19.1 we changed the `is_company` field to a computed
stored field.
This change needs to be reflected correctly in many localisations
where the default computed value is too naive.
This commit is introducing a generic fix for most l10n that depends
on the module `l10n_latam_base`.
Improve the test coverage for the computation.
Note: This is not strictly necessary for this fix
on Enterprise side, since we removed the invisibility
condition but in case of some customization relying
on it it's safer if we can deduce it correctly.
Enterprise: https://github.com/odoo/enterprise/pull/114403
Related: https://github.com/odoo/odoo/pull/211043
task-6141307
Forward-Port-Of: odoo/odoo#261414
Forward-Port-Of: odoo/odoo#260224This update resolves an issue where Peruvian identifiers (like driver licenses) were not being displayed correctly in the system. The team removed a restrictive visibility condition on these fields, ensuring they are always visible. This ensures accurate reporting and data capture for Peruvian businesses.
Original PR description
In 19.1 we changed the `is_company` field to a computed stored field. That change broke the visibility for some Peruvian identifiers (driver license, etc). This commit removes the visibility condition on those fields to be displayed all the time. Note: we still add the correct compute on related Community commit for sake of correctness and completeness. Community: https://github.com/odoo/odoo/pull/260224 Related: https://github.com/odoo/odoo/pull/211043 task-6141307 Forward-Port-Of: odoo/enterprise#115204 Forward-Port-Of: odoo/enterprise#114403
This update fixes a problem where Wise payments were failing due to slight differences in recipient information (like spacing or casing). Now, the system uses only bank account details (like account number and routing number) to match recipients, ensuring accurate and reliable payments. This also consolidates IBAN and SWIFT recipients for broader compatibility.
Original PR description
Previously, _generate_wise_key included partner name and email in the matching key. If these differed between Odoo and Wise (e.g. trailing spaces, casing), the match would fail and a duplicate recipient was created. Use only financial identifiers (account type, routing number, account number) which are the actual unique identifiers for bank accounts. This is for example important with IBAN accounts as the won't have an email stored in Wise. From this we combine IBAN and SWIFT recipients into one non-US group. Forward-Port-Of: odoo/enterprise#115209 Forward-Port-Of: odoo/enterprise#113234
This update fixes inaccuracies in how tax amounts are calculated for Argentina (l10n_ar) within Odoo. The changes ensure correct tax calculations by leveraging the core tax engine, improving accuracy and preparing for future adjustments to Argentina's tax regulations. This update is related to a larger effort to ensure accurate tax reporting.
Original PR description
This commit refactors the tax amount calculations on the `_get_vat` and `_l10n_ar_get_amounts` method so that it uses the tax computation engine helpers properly, to prepare for any future fixes done on how Argentina tax calculations differs from all other localizations. This replaces all move line queries with the proper `base_line` calculation, with the proper aggregating methods. related-enterprise-PR: https://github.com/odoo/enterprise/pull/92639 task-4891206 Forward-Port-Of: odoo/odoo#261256 Forward-Port-Of: odoo/odoo#223393
This update fixes inaccuracies in how tax amounts are calculated for Arabic VAT transactions within the Odoo system. By utilizing the system's tax calculation engine, the changes ensure more precise and reliable tax amounts are generated, particularly for sales and invoices. This improves financial reporting accuracy.
Original PR description
- Rewrite all tax amounts calculations on `_get_tributes` and `_get_line_details` to properly use the tax computation engine helpers (`base_line`, and aggregating methods) - Ensure that all final amounts from the calculation are formatted with `float_repr` with appropriate precision. related-community-PR: https://github.com/odoo/odoo/pull/223393 task-4891206 Forward-Port-Of: odoo/enterprise#115069 Forward-Port-Of: odoo/enterprise#92639
A minor visual issue in the loyalty wizard has been resolved. The 'Discard' button was missing its label, making it difficult for users to identify. This commit restores the label, ensuring clarity and ease of use for this feature.
Original PR description
The label on the Discard button was accidentally removed in forward-port commit 344661bb057bec1415651dadbd6069a1a543f208. Without the label, the button is not visible/identifiable in the popup. This commit restores the missing label. Before: <img width="1002" height="259" alt="image" src="https://github.com/user-attachments/assets/0651d5f8-379e-4084-ad42-5d5931eaeb52" /> After: <img width="1003" height="270" alt="image" src="https://github.com/user-attachments/assets/0d98b7d0-06e1-4d7f-be1f-9fd3e5a87f07" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update addresses a minor issue where query counts weren't accurately reflected during post-installation testing of the demo data. The fix ensures that performance tests run correctly, providing more reliable results for the demo environment. This improves the overall stability and predictability of the Odoo demo.
Original PR description
Query counts were updated for demo data. Missed a query update in post install test in #260655. runbot-242325 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A recent update introduced a search function on the Indian Company homepage, which triggered a technical error. This fix addresses a problem where the search functionality would fail due to an incorrect handling of report data. The update ensures a stable search experience for users on the Indian Company version.
Original PR description
Steps to reproduce: 1. Install l10n_in_reports and switch to Indian Company. 2. Go to homepage and try to type something and search on the search box. A traceback will appear. Cause: In recent updates, it is now possible to search report varients through the search menu, so while fetching varients while preparing search results, this leads us to `_is_available_for` method. The cause lies in how `.get()` is being used. `_get_external_ids` returns `id: []` if no external id is linked to it, and here we do `external_ids.get(report.id, [None])[0]` and this will always give us [] if no external id is there. hence trying to access the 0th element causes traceback. This commit fixes that by safely evaluating to `[None]`.
This update resolves an issue where the SBR tax report wizard would crash if an SBR certificate wasn't configured. The fix checks for the certificate's existence and displays a helpful message to the user, guiding them to the Accounting Settings. This ensures the report generation process remains stable and reliable.
Original PR description
In the SBR tax report wizard, the code previously attempted to access the `pem_certificate` attribute on a potentially empty recordset if no certificate was configured (see [here](https://github.com/odoo-dev/enterprise/commit/0b50021bdae54779396d75d3cddbd9eb42571553)). This resulted in an AttributeError before the validation check could trigger the intended RedirectWarning. This commit fixes the logic by: * Checking for the existence of the `cert_sudo` recordset immediately after retrieval. * Raising the RedirectWarning if the certificate record is missing, guiding the user to the Accounting Settings. * Accessing the certificate and private key content only after confirming the record exists. no-task
This update addresses a minor issue in the account reports module, specifically correcting a sign error for the 'cta' value. The change simplifies existing queries and functions, ensuring accurate reporting and data processing. This ensures consistent and reliable financial reporting.
Original PR description
Followup PR of odoo/enterprise#103529 * Simplification of some queries * Simplification of functions * Sign correction for cta value
This update addresses an issue where Coda bank statement files sometimes lacked transaction details, leading to empty payment reference fields in Odoo. This resulted in a 'No description' default being added to the statement line, which has now been corrected. This ensures accurate financial reporting.
Original PR description
It can happens that coda file with transaction have no communication or structure communication. This can cause problem since we will have an empty payment_ref for the statement line. This will add "No description" as a default value. task-6045138 Forward-Port-Of: odoo/enterprise#111300
This update corrects a problem where the AccountID in Odoo's FAIA XML export was not consistently matching account definitions. This ensures accurate financial reporting for Luxembourg (l10n_lu_reports) by aligning data across key Odoo systems. The fix was part of a larger effort to improve the reliability of FAIA exports.
Original PR description
This is one of several commits fixing the FAIA xml export. The Invoice/Line/AccountID element in SourceDocuments/SalesInvoices and SourceDocuments/PurchaseInvoices must match an account defined in MasterFiles/GeneralLedgerAccounts/Account/AccountID. As the latter uses account_code since PR #65221, the former should too. opw-5427296 [Link](https://www.odoo.com/odoo/unassigned-tasks/5427296) Forward-Port-Of: odoo/enterprise#114254 Forward-Port-Of: odoo/enterprise#113455
This update fixes an issue where group payments were incorrectly processing the full amount of bills with multiple installments. Now, payments accurately reflect the outstanding balance of the first installment of each bill, ensuring correct accounting and payment reconciliation. This improves the accuracy of financial reporting.
Original PR description
Steps to reproduce: 1- Install Accounting and make sure "Batch Payments" is enabled in settings 2- Go to [Accounting -> Vendors -> Bills] 3- Create two bills for the same vendor, ensuring one of them has multiple installments (i.e payment term with 3 installments) 4- Confirm the bills 5- In list view, select both bills and another bill from a different vendor and click on Pay 6- Select "Group Payments" and confirm the payment Description of issue: The batch payment of the first vendor has the full amount for both bills Expected behavior: The payment should consider the full amount of the first bill and the first installment only of the second bill opw-5969972 Forward-Port-Of: odoo/odoo#261371 Forward-Port-Of: odoo/odoo#257871
This update resolves an issue preventing account return tours from functioning correctly across all Odoo localization modules. The fix addresses a missing tag that caused errors, specifically related to submitting actions, ensuring consistent functionality for users with different language settings.
Original PR description
Before, the account return tour was not running with every l10n installed du to a missing tags. This leads to errors that were not catched like missing super call on a submit action. Forward-Port-Of: odoo/enterprise#115290
This update resolves an issue where copying and pasting content from the blog post editor unexpectedly modified the original field. The fix adds a setting to the editor to prevent copying outside of the editable area, ensuring data integrity and preventing unwanted changes to the source records.
Original PR description
Problem: When copying the blog post title and pasting it elsewhere, editing the pasted content unexpectedly modifies the original field source. Cause: The copied HTML retains `data-oe-*` attributes, causing the editor to treat the pasted content as a field binding and propagate changes back to the original record. Solution: `contenteditable="true"` should be added on fields (`o_savable`) to prevent copying outside of savable area. Steps to Reproduce: - Copy title of blog post. - Paste it elsewhere in editable. - Edit the pasted text. - Observe the original field source also changes. opw-6105714 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258880
This update resolves an issue where invoice transaction IDs in financial reports (FAIA export) didn't consistently match those in the general ledger. The fix ensures all transaction IDs are synchronized, improving the accuracy and reliability of financial data exports. This prevents potential discrepancies in reporting.
Original PR description
The Invoice/TransactionID element in SourceDocuments/SalesInvoices and SourceDocuments/PurchaseInvoices must match the corresponding Transaction/TransactionID in the GeneralLedgerEntries section. As the latter uses the entry name since PR odoo#58728, the former should too. opw-6111343, opw-542729 Forward-Port-Of: odoo/enterprise#113846
A bug in a test for the restaurant point-of-sale module caused order data to be incorrectly updated, leading to potential data inconsistencies. This fix addresses a timing issue within the test process, ensuring order information is accurately recorded and synchronized.
Original PR description
In the tour test_customer_alone_saved, the test was creating an order, then go on the ticket screen and then come back on the product screen to change the customer to go again on the ticket screen and come back on product screen to check that the customer did not changed. The problem was that when going to the ticket screen the first time, the order was synced with the server but the answer might come after the test changed the customer. When going the second time on the ticket screen, the order was changed with the information of the backend and the user was lost. This is all due to the test that are too fast. runbot-error: 238467 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253587
This update corrects and improves the Sri Lankan accounting integration (l10n_lk) within Odoo. It includes new chart of accounts (CoA) elements, revised tax settings, and adjustments to account mappings to align with Sri Lankan accounting standards. This ensures accurate financial reporting for Sri Lankan businesses using Odoo.
Original PR description
Updates the CoA with new accounts, updated taxes, and adjusted default account mapping to better reflect standard Sri Lankan accounting practice. Enterprise PR: https://github.com/odoo/enterprise/pull/114768 task-6141758 Forward-Port-Of: odoo/odoo#260920
This update simplifies the setup of financial accounts by reducing the complexity of Balance Sheet formulas. New equity and liability accounts have been added to the Balance Sheet, providing a more accurate and flexible reporting structure for Sri Lankan businesses. This change enhances the overall financial reporting capabilities within the Odoo Enterprise system.
Original PR description
Reduces Balance Sheet account code formulas from 3-digit to 2-digit prefixes to make the COA setup more flexible. New equity and liability lines are also added to the Balance Sheet. Community PR: https://github.com/odoo/odoo/pull/260920 task-6141758 Forward-Port-Of: odoo/enterprise#114768
This update fixes an error in how time off is calculated when 'Ignore Public Holidays' is enabled. Previously, the system incorrectly added public holidays to the leave duration, leading to inaccurate 'Approved Time Off' figures. The change ensures that public holidays are excluded from the calculation, aligning with the intended functionality.
Original PR description
# Setup You'll need a User with : - An active contract (for easiness of testing, a contract that started long ago with 8hrs/day) # How to reproduce - Create a new Time Off type with "Ignore Public…
# Setup
You'll need a User with :
- An active contract (for easiness of testing, a contract that started long ago with 8hrs/day)
# How to reproduce
- Create a new Time Off type with "Ignore Public Holidays" enabled
- Create a Public Holiday for Period X
- Create A Time Off request for the User for a Period Y that contains Period X
- Go to the Time Off Ledger
- Remove the Missing Hours filter and search for the dates in Period Y
Exemple of periods :
- Period X => Feb 10 2026 - Feb 10 2026
- Period Y => Feb 9 2026 - Feb 11 2026
# The problem
The "Approved Time Off" and "Difference" values are wrong.
With the given exemples, we'll see Feb 9 and Feb 11 with "Approved Time Off" values of 12hrs, which is wrong since the employee is supposed to work 8hrs a day, so he should have a time off of also 8hrs.
# Cause
The calculation for "Approved Time Off" is the following :
Divide the `number_of_hours` of a hr_leave
By the number of working days during the period of the leave
Using our exemple, we get :
`number_of_hours` = 24hrs
number of working days = 2
Approved Time Off = 24hrs / 2 => 12hrs, but we expect 8hrs
The `number_of_hours` is correct since we checked "Ignore Public Holidays" (which actually means : include the public holidays in the number of hours of a leave)
The problem is that the aggregation for the number of working days excludes automatically
public holidays, without paying attention to the value of "Ignore Public Holidays" :
https://github.com/odoo/odoo/blob/5e623af55fba64e812db6bcaf06d8f7c5d08f055/addons/hr_holidays_attendance/report/hr_leave_attendance_report.py#L193-L202
Explanation for this part of the query : we only keep days where there is no record in
resource_calendar_leaves (`WHERE rcl2.id IS NULL`) that contains that day
and that are considered public (`AND rcl2.resource_id IS NULL`)
# Proposed Solution
We add a `JOIN hr_leave_type` to be able to get the value for
`include_public_holidays_in_duration` ("Ignore Public Holidays").
Then, we make it so we exclude the Public Holidays only if that value is
false (`AND NOT lvt.include_public_holidays_in_duration`)
opw-6082422
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#261259
Forward-Port-Of: odoo/odoo#258963This update resolves an issue where duplicating an employee would incorrectly copy their bank account information, leading to salary payments being routed to the same account for both employees. The fix ensures that the bank account is cleared during duplication, preventing this duplication and maintaining accurate payroll processing.
Original PR description
Steps: - Duplicate an employee. - Check that the bank account is copied. - Modify the bank account on the duplicated employee. - Verify the original employee’s bank account. Issue: - When duplicating an employee, the bank account was copied as well, causing both employees to use the same account. Updating it for one also changed it for the other, leading to both salaries being paid to the same account. Fix: - Set the 'bank_account_id' field to not be copied during duplication, ensuring the field is cleared for the duplicated employee. task-6093406 Forward-Port-Of: odoo/odoo#261505 Forward-Port-Of: odoo/odoo#259405
This update resolves a failing test related to WorldLine integration within our self-order point-of-sale system. The fix ensures that the test only runs if both necessary modules (`pos_self_order_iot` and `pos_iot_worldline`) are installed, preventing errors and improving test reliability.
Original PR description
To test WorldLine in self order, we need both `pos_self_order_iot` and `pos_iot_worldline`. We then skip the test if `pos_iot_worldline` isn't installed. Forward-Port-Of: odoo/enterprise#115282
This update fixes an issue where the contact type for related contacts wasn't being translated in the contact list view. It now correctly displays the contact type in the user's preferred language, mirroring the translation seen in the Kanban view. This improves the user experience and ensures consistent data presentation.
Original PR description
Problem: When the contact type is set for a related (child) contact, the contact type is shown in English next to the contact name in the contact list view. It should be translated to the user…
Problem: When the contact type is set for a related (child) contact, the contact type is shown in English next to the contact name in the contact list view. It should be translated to the user language. It is correctly translated in the Kanban view. Steps to reproduce: 1. Install the Contacts app. 2. Create a contact or go to an existing contact 3. Add a related (child) contact and set its contact type to any type (i.e. Invoice Address) 4. Change the user language to any language other than English 5. Go back to the contact list view and check the name of the related (child) contact. See how the contact type appearing in the name is in English instead of being translated, while it is correctly translated in the Kanban view. Cause: The list view uses the 'complete_name' field which is not translated, while the Kanban view uses the 'display_name' field which is translated. Solution: Use the 'display_name' field instead of 'complete_name' in the list view. opw-5947987 Forward-Port-Of: odoo/odoo#261592 Forward-Port-Of: odoo/odoo#257539
This update fixes an issue where contact types for related contacts were displayed in English within the contact list view, regardless of the user's language setting. The change ensures that contact types are now correctly translated to the user's preferred language, matching the behavior in the Kanban view. This improves the user experience for international users.
Original PR description
Problem: When the contact type is set for a related (child) contact, the contact type is shown in English next to the contact name in the contact list view. It should be translated to the user…
Problem: When the contact type is set for a related (child) contact, the contact type is shown in English next to the contact name in the contact list view. It should be translated to the user language. It is correctly translated in the Kanban view. Steps to reproduce: 1. Install the Contacts app. 2. Create a contact or go to an existing contact 3. Add a related (child) contact and set its contact type to any type (i.e. Invoice Address) 4. Change the user language to any language other than English 5. Go back to the contact list view and check the name of the related (child) contact. See how the contact type appearing in the name is in English instead of being translated, while it is correctly translated in the Kanban view. Cause: The list view uses the 'complete_name' field which is not translated, while the Kanban view uses the 'display_name' field which is translated. Solution: Use the 'display_name' field instead of 'complete_name' in the list view. opw-5947987 Forward-Port-Of: odoo/enterprise#115331 Forward-Port-Of: odoo/enterprise#114786
This update fixes an issue where product URLs in multilingual websites incorrectly included the category path. Previously, the canonical URL wasn't properly handling language codes, leading to incorrect links. This change ensures that product URLs are correctly generated regardless of the website's language, improving SEO and user experience.
Original PR description
Issue: --- Canonical address is not correctly calculated in non-default lang. Steps to reproduce: 1- Create a website with 2 lang: en, fr 2- Create a product with a website category. 3- Navigate to…
Issue: --- Canonical address is not correctly calculated in non-default lang. Steps to reproduce: 1- Create a website with 2 lang: en, fr 2- Create a product with a website category. 3- Navigate to the shop in fr. 4- Open the category, then open the product. 5- Open console, and search for canonical. As you see, in the second language, the canonical address includes the category address which is wrong. If you visit in the default lang, the canonical correctly refers to the url without category. Cause: --- This is because `_get_canonical_url` override relies on `self.env['ir.http']._match`, which will not work with an url prefixed by language code, raising `NotFound`. This leads to rule to be set as `None`. As a result canonical address will be set as the canonical address from `website` module's implementation, which doesn't take website category case into account. This lead to canonical address of `/lang-code/shop/category/product` to be itself. opw-6086206 Forward-Port-Of: odoo/odoo#258834
This update resolves an issue where IoT events were missed due to a failure in the longpolling fallback mechanism. Now, if longpolling requests fail, the system automatically switches to using the more reliable WebSocket connection, preventing disruptions like failed Worldline payment confirmations. This ensures consistent event delivery.
Original PR description
Community PR: https://github.com/odoo/odoo/pull/260931 Before this commit, if `onMessage` in `iot_http_service` was called directly, it would fail to fallback to websocket if the longpolling request failed, causing events to be missed. One symptom of this is Worldline payments failing to confirm when using websocket. After this commit, the `_longpolling` method will now throw an error in this case, causing the fallback mechanism to attempt websocket instead. Forward-Port-Of: odoo/enterprise#115143 Forward-Port-Of: odoo/enterprise#114779
This update allows administrators to easily control the automatic resetting of subscription users, providing greater flexibility in managing user accounts. Previously, automated user resets were difficult to override, but this change simplifies the process and offers more control. This improves operational efficiency and reduces potential issues related to user account management.
Original PR description
After this commit, the auto resetting of subscription user is overridable. Doing business logic in CRUD methods makes them impossible to bypass, by encapsulating the logic in another method, it would be easily overridable. Forward-Port-Of: odoo/enterprise#114459 Forward-Port-Of: odoo/enterprise#114055
A minor bug preventing users from clocking in with the Blackbox POS was resolved. The fix corrects a typo that caused an error when generating receipt data, ensuring proper functionality for this key POS feature. This resolves a technical issue impacting POS operations.
Original PR description
There is a typo trying to assign the server version to `this` instead of the `data` object which is used for the receipt. This causes a `cannot set properties of undefined` error when trying to clock in with a blackbox Forward-Port-Of: odoo/enterprise#115098
This update corrects a discrepancy in the system's tests related to new Ecuadorian withholding tax percentages (as defined by a recent government regulation). The changes ensure accurate calculations for purchases and returns, aligning with current tax requirements. This ensures compliance and accurate reporting for our Ecuadorian clients.
Original PR description
In accordance with the implementation of the new withholding tax percentages according to "Resolución N.º NAC-DGERCGC26-00000009" for Ecuador, following internal implementation guidelines by TRESCLOUD. Unit tests are updated to be based on the new withholding percentages. BP #110343 Forward-Port-Of: odoo/enterprise#112957 Forward-Port-Of: odoo/enterprise#110712
This update resolves a bug preventing correct discount allocations when invoices are created with sales in foreign currencies. The fix ensures invoices are balanced accurately, addressing a previous error that caused invoice creation failures. This improves the reliability of our invoicing process for international transactions.
Original PR description
**STEP TO REPRODUCE** 1. Install the sale and accounting module. 2. Create 2 products, and setup each one with a different income account. 3. From the accounting settings, setup an account for Invoice Line discount -> Customer Invoice account. 4. Enable a currency, and create a pricelist for this currency. 5. Create the following SO: pricelist -> the pricelist you created previously. currency rate : 0.000717398539 line a: product_a, price 10, discount 57.85% line b: product_b, price 70, discount 57.85% From this SO, try to create an invoice. It will fail, saying the invoice it tried to create is unbalanced. opw-5974048 Forward-Port-Of: odoo/odoo#257897
This update fixes a minor visual issue where the IM status icon in the user menu was slightly misaligned. The change ensures the icon is centered within its container, creating a cleaner and more professional user interface. This improves the overall user experience.
Original PR description
**Current behavior before PR:** Since this https://github.com/odoo/odoo/pull/246182, the IM status icon in the user menu appears misaligned with its surrounding context, causing a slight visual offset. **Desired behavior after PR is merged:** This commit ensures that the IM status icon is properly aligned by centering it within its container. task-[6012657](https://www.odoo.com/odoo/project/1519/tasks/6012657) | Before | After | |--------|--------| | <img width="308" height="46" alt="image" src="https://github.com/user-attachments/assets/214083b2-5013-41ab-a02f-8f8d510b1ac5" /> | <img width="311" height="43" alt="image" src="https://github.com/user-attachments/assets/9a77718c-84d4-4be8-8cc4-a65516e957cd" /> | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261503
This update fixes a bug where bank statement reconciliations could incorrectly link transactions from different companies. The fix ensures that payments and bank statements share the same company hierarchy, preventing foreign tax lines from being added to the wrong company's financial records. This improves the accuracy of financial reporting.
Original PR description
ticket-5992100 When auto-reconciling bank statement lines, the end-to-end UUID lookup correctly checked that matched AMLs and their payment belong to the same company hierarchy, but missed checking that the payment also belongs to the same company hierarchy as the bank statement line itself. This allowed a payment from an unrelated company (sharing the same end-to-end UUID from an inter-company bank transfer) to be matched against another company's bank transaction, pulling foreign tax lines into the wrong company's journal entry. Fix by adding the same parent-path company check between the bank statement line and the payment. Forward-Port-Of: odoo/enterprise#114881 Forward-Port-Of: odoo/enterprise#113279
This update fixes issues with the AI chat interface, primarily addressing readability by reducing header font sizes and correcting formatting errors in AI responses. Specifically, the formatting of bold text within AI-generated content has been resolved, ensuring accurate display of text.
Original PR description
- The font-size of h1/h2 headers is large given the small size of chat channels which makes it harder to read the rest of the text. So, the font-size of h1/h2 headers is reduced in ai chat channels. - This commit removes the double border at the bottom of tables and updates the table borders by using table-bordered bootstrap class instead of border. - This commit also fixes an error where markdown2 2.4.11 doesn't detect the boundaries of bold markup properly causing asterisks to appear randomly inside AI responses. For example, "The **dog**, the **cat** and the **rat**" becomes "The <strong>dog<em>*, the *</em>cat<em>* and the *</em>rat</strong>" where it should only use <strong>dog/cat/rat</strong> task-6109286 Forward-Port-Of: odoo/enterprise#114592
This update fixes a technical issue that could cause the Odoo application to unexpectedly crash when multiple drag sequences were initiated. The fix ensures that the cancellation callback is available before the variable is assigned, preventing the crash in these specific, rare scenarios. This improves overall application stability.
Original PR description
### [FIX] web: fix crash when cancelling drag sequence Before this commit: drag sequences could be aborted by new drag sequences; the way this worked is that a new sequence would register its "cancel" callback in a global variable, and when another sequence is started, it calls that variable to cancel the previous one. The issue was that the variable was assigned too early; before the actual "cancel" callback was available. This means that in edge cases where 2 sequences would be triggered in less than (effectively) a resolved promise, the callback would not be available and a crash would occur. This commit moves the variable assignment *after* the "cancel" callback is made available, ensuring there is no crash. Runbot [243113](https://runbot.odoo.com/odoo/error/243113) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261345 Forward-Port-Of: odoo/odoo#260594
This update resolves an issue where the quick create feature for product variants in the Bill of Materials form was incorrectly creating new, unrelated product templates instead of the intended variants. To ensure correct variant creation, the 'Create' and 'Create and Edit' options have been disabled, requiring users to create variants directly on the product template.
Original PR description
Steps to produce: --- - Install `mrp`. - Go to Manufacturing > Products > Bills of Materials. - Click Create, select a product. - In the Product Variant field, type any value and click "Create".…
Steps to produce: --- - Install `mrp`. - Go to Manufacturing > Products > Bills of Materials. - Click Create, select a product. - In the Product Variant field, type any value and click "Create". Issue: --- Using quick create on the Product Variant field does not create a variant of the selected product template. Instead, it creates a completely new, unrelated `product.template`. This is because the `create()` method on `product.product` is overridden to call super() with context `create_product_product=False`, which suppresses direct variant creation and forces creation through `product.template` instead, see [1]. **Why passing `default_product_tmpl_id` does not help:** One might expect that passing `default_product_tmpl_id` in the field context would cause the newly quick-created `product.product` to be linked to the already-selected `product.template`. However, because of the `create()` override above (introduced in [commit]), the variant creation is always redirected to `product.template`, ignoring any `default_product_tmpl_id` passed in context. It is therefore not possible in any case to quick-create a `product.product` that is correctly and directly linked to the currently selected `product.template`. Fix: --- Disable the "Create" and "Create and Edit" options. Since there is no way to quick-create a `product.product` that is correctly linked to the currently selected `product.template`, the user must create the variant directly on the product template first. [1]https://github.com/odoo/odoo/blob/f04d79d44873d0f1c35303a1a892f3a3a394ea17/addons/product/models/product_product.py#L364-L368 [commit]: https://github.com/odoo/odoo/commit/7389345696720255a9d3c72ca1d9c2f4e4ecd7b8 opw-6127738 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261316 Forward-Port-Of: odoo/odoo#259776
This update resolves a technical issue preventing invoices sent to Poland's KSeF system from being properly processed. The fix ensures that email and phone number fields are only included in the invoice XML if the buyer actually has that information, avoiding errors that caused rejection by the KSeF system. This improves invoice compatibility and reduces processing delays.
Original PR description
Before this commit: Steps 1. Create a Polish company 2. Create and send an invoice to KSeF where the buyer has no email or no phone number 3. KSeF rejects the invoice with error code 450 (semantic verification error) This happens because `Email` and `Telefon` elements are always rendered inside `DaneKontaktowe`, even when their values are empty, producing invalid empty tags. After this commit: Add `t-if="buyer.email"` and `t-if="buyer.phone"` guards on each field so that `Email` and `Telefon` are only rendered when a value is present. opw-6124187 Forward-Port-Of: odoo/odoo#259646
This update ensures that the AI chat window opens in full-screen mode, regardless of how it's initiated – through the system tray or command palette. Previously, the chat would open in a background window, which has now been resolved for a better user experience.
Original PR description
Prior to this commit, when opening the chat with an agent from the systray button, the chat window was opened in the background. This commit fixes the issue by adding a call to `channel.open` which opens the chat when in full-screen mode. This commit also fixes an issue where the chat window wasn't properly opened when done from the command palette. task-5172978 Forward-Port-Of: odoo/enterprise#114840 Forward-Port-Of: odoo/enterprise#114598
This update ensures that when scanning a GS1 barcode on a packaged product, the system correctly incorporates the product's due date. Previously, the system ignored the due date information on the packaging, leading to inaccurate expiration tracking. This change improves inventory management accuracy for products sold in packaged form.
Original PR description
Issue
-----
Scanning a GS1 barcode containing:
- packaging
- lot
- due date
disregards the due date when creating the new lot.
Steps to reproduce
-----
- Enable GS1 nomenclature & packagings
- Create a product
- barcode 23456789012344
- packaging with barcode 01234567890128
- some on hand quantity
- Create a delivery for a full packaging of the product
- Open the delivery in barcode
- Scan 02 01234567890128 15 270101 10 LOT1
- Validate
- Open the lot
> Expiration date is set to today
Cause
-----
The code expects the product be scanned, there is no logic to retrieve it from the packaging when missing.
-----
Ticket:
opw-6073489
Forward-Port-Of: odoo/enterprise#114327
Forward-Port-Of: odoo/enterprise#112490This update fixes an issue where power buttons within the Knowledge editor were being hidden due to incorrect boundary calculations. The change ensures the editor accurately accounts for margins, guaranteeing that power buttons remain visible for all users. This improves the user experience and functionality of the Knowledge editor.
Original PR description
**Current behavior before PR:** - Power buttons in Knowledge were hidden incorrectly because `editableRect.width` was used as the boundary. Since the editable area has margins applied, this width no longer reflects the actual boundary, causing buttons to be hidden. **Desired behavior after PR is merged:** - Use `editableRect.right + referenceRect.left` instead of `editableRect.width` to determine the correct boundary, ensuring power buttons remain visible in when editable area has margin applied to it. task-6102944 Forward-Port-Of: odoo/odoo#259532
This update ensures that IoT boxes send the correct data to the Odoo database. A missing field was corrected in the 'subscribe' message, allowing the database to properly process information from the IoT devices. This improves the reliability of data updates from our IoT integrations.
Original PR description
In odoo/odoo#260380, a new required field was added to the websocket `subscribe` message, `check_outdated`. This commit adds this field to the subscribe message sent from the IoT box so that the DB can process it successfully. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261687
This update corrects a potential error in the account reports module where custom modules could cause conflicts when querying for the 'state' field. By using aliases for column references, the system now correctly identifies and resolves ambiguous column names, ensuring accurate reporting across all client configurations.
Original PR description
Issue: ------- There are cases where clients might have the same named 'state' field/column for custom modules in the models 'res.partner' or 'account.fiscal.position' and therefore they might get conflicted with the standard one's when the below query executes, https://github.com/odoo/enterprise/pull/84391/changes#diff-2f90e40d6e7b35681a4af03037e8e5ee0fddab2ba0876d9f148bf79786a91c29R1359 and can cause ``` File "/home/odoo/src/enterprise/account_reports/models/account_return.py", line 2204, in _check_suite_common_vat_report self.env.cr.execute(SQL( File "/home/odoo/src/odoo/odoo/sql_db.py", line 433, in execute self._obj.execute(query, params) psycopg2.errors.AmbiguousColumn: column reference "state" is ambiguous LINE 9: state = 'posted' ``` Solution: ------------ Use the corresponding alias while mentioning the column i.e; `move.state = 'posted'` OPW - 6044665 Forward-Port-Of: odoo/enterprise#114341
This update fixes an issue where stock wasn't being properly reserved for delivery orders when stock arrived at a child location within the warehouse system. Now, when a delivery order is waiting for stock to arrive at a child location, the system automatically reserves the appropriate quantity, ensuring accurate stock tracking. This prevents over-delivery and improves order fulfillment accuracy.
Original PR description
Steps to reproduce: - Create a storable product with no stock on hand - Create a delivery order from WH/Stock → state is "Waiting for Availability" - Create a receipt with destination WH/Stock/Shelf1 and validate it Problem: The incoming quantity is not reserved against the waiting delivery, even though WH/Stock/Shelf1 is a child of WH/Stock. opw-6124879 Forward-Port-Of: odoo/odoo#261334 Forward-Port-Of: odoo/odoo#261072
This update resolves two issues impacting how users manage manufacturing orders through the Barcode app. Previously, changing the UoM after confirmation or modifying the 'Produce Quantity' would reset, leading to data inconsistencies. This fix ensures that UoM changes are correctly applied and that entered quantity values are preserved, improving data accuracy and usability.
Original PR description
### Issue Two bugs reported in the Barcode app / Manufacturing Order flow: **1. UoM change after confirm leaves MO inconsistent** Changing the UoM on a confirmed MO via the Barcode app does not…
### Issue Two bugs reported in the Barcode app / Manufacturing Order flow: **1. UoM change after confirm leaves MO inconsistent** Changing the UoM on a confirmed MO via the Barcode app does not recalculate `product_qty` / `qty_producing`. The backend locks the UoM after confirm — the Barcode view did not. **2. `qty_producing` reset on wizard open/close** Typing a value in `qty_producing` then opening the "Change Qty to Produce" widget (even closing without saving) caused the typed value to vanish. Root cause: the widget's `onClose` calls `env.model.load()`, which refetches from DB and discards any unsaved form edits. ### Fix - `product_uom_id` in the Barcode MO form is now readonly once `state != 'draft'`, matching the backend. - `openChangeQtyWizard` now saves the record before opening the wizard, so pending edits survive the reload. ### Steps to reproduce **UoM bug** 1. Create an MO, confirm it. 2. Open it in the Barcode app. 3. Try to change the UoM → it was editable (bug). **Qty reset bug** 1. Open a confirmed MO in the Barcode app, go to the header product page. 2. Type a value in `qty_producing` (e.g. `3`). 3. Click the `/ X` button next to it (opens the Change Qty wizard) then close it without clicking "Set Quantity". 4. `qty_producing` reverts to its previous value (bug). ### After the fix - UoM field is greyed out once the MO is confirmed. - Typed value in `qty_producing` is preserved after opening and closing the wizard. opw-5809178 Forward-Port-Of: odoo/enterprise#114452 Forward-Port-Of: odoo/enterprise#114075
This update fixes a problem where payment reminder emails for subscriptions were missing the subscription's end date. The change ensures that all payment reminder emails, regardless of how they're generated (automated or manually through the email composer), accurately display the subscription's closing date. This improves the clarity and accuracy of communication with customers.
Original PR description
### Issue before this commit: When sending a payment reminder email for a subscription using the email composer, the template was not correctly populated with the expected dynamic values. In…
### Issue before this commit: When sending a payment reminder email for a subscription using the email composer, the template was not correctly populated with the expected dynamic values. In particular, fields such as the subscription closing date and the subscription code were missing. ### Steps to reproduce the issue: 1. Install subscription and go to that app 2. Open one subscription 3. Send message > Load template: "Subscription: Payment Reminder" 4. Sentence is incomplete: missing end date of the subscription ### Cause of the issue: The issue was caused by the absence of a proper context injection when rendering the email template from the mail.compose.message wizard. The template relied on context variables like date_close, but these values were not being computed nor passed during manual email composition. Unlike automated flows, the composer did not provide the subscription-specific context required by the template. ### Reason to introduce the fix: The fix makes the payment reminder and closing templates self-sufficient by replacing context-based values with fields and helper methods directly available on the subscription record. A dedicated method is introduced to compute the subscription close date consistently, so the templates render the expected values both in automated flows and when manually loaded from the email composer. opw-6031613 Forward-Port-Of: odoo/enterprise#114839 Forward-Port-Of: odoo/enterprise#111801
This update fixes an issue where stock quantities weren't always correctly reflected in the unit of measure of purchase orders. It now automatically creates pickings for partial and empty orders, ensuring accurate stock tracking. Additionally, the demo stock data was adjusted to prevent negative stock levels, maintaining the integrity of our demo environment.
Original PR description
Make sure that the quantity received is in the unit of measure of the purchase order line. Also, when installing stock, create pickings for partial and empty sale/purchase orders. Finally, since creating we're creating more pickings, we need to raise the demo stock of product_product_12 to not be in negative stock for other modules demo data. task 5431550 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245281
A minor technical issue was resolved where the wrong function was being utilized within the VoIP sales module. This fix ensures accurate processing of VoIP calls related to sales transactions. The change improves the stability and reliability of the sales process.
Original PR description
Shh! We used the wrong function. Forward-Port-Of: odoo/enterprise#114869
This update fixes an issue where the ‘Ordered Quantity’ on the delivery slip was incorrectly calculated, leading to inaccurate reporting. Now, the ‘Ordered Quantity’ always matches the actual delivered quantity, ensuring accurate inventory tracking and reporting, especially when no backorders are used.
Original PR description
**Steps to reproduce:** * Install the *Inventory* (`stock`) module. * Create a *Storable Product* and set some *On Hand* quantity. * Go to *Inventory → Operations → Receipts*. * Create a new receipt.…
**Steps to reproduce:**
* Install the *Inventory* (`stock`) module.
* Create a *Storable Product* and set some *On Hand* quantity.
* Go to *Inventory → Operations → Receipts*.
* Create a new receipt.
* Add the product with a *Demand* quantity (e.g. 10).
* Validate the receipt:
* Case 1: Validate with less quantity than demand (e.g. 8) and choose *No Backorder*.
* Case 2: Validate with more quantity than demand (e.g. 12).
* Click on *Print( Delivery Slip)*.
**Observed behavior:**
* The *Ordered Quantity* is equal to the *Delivered Quantity*.
* Case 1 (Demand=10, Done=8):
* Ordered = 8, Delivered = 8.
* Case 2 (Demand=10, Done=12):
* Ordered = 12, Delivered = 12.
**Expected behavior:**
* Case 1 (Demand=10, Done=8):
* Ordered = 10, Delivered = 8.
* Case 2 (Demand=10, Done=12):
* Ordered = 10, Delivered = 12.
**Cause:**
* Clicking on *Print* triggers `stock.action_report_delivery`: https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/views/stock_picking_views.xml#L156
* This renders `stock.report_deliveryslip`: https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/report/stock_report_views.xml#L14
* The QWeb template calls `report_delivery_document`: https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/report/report_deliveryslip.xml#L288-L292
* Which relies on `_get_aggregated_product_quantities`: https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/report/report_deliveryslip.xml#L157
CASE- 1
* When validating with *less quantity* and *no backorder*:
* In `_get_aggregated_product_quantities`, `qty_ordered` is initialized to `None` and only set when `backorders and not kwargs.get('strict')`: https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/models/stock_move_line.py#L881
* If no backorder exists, the condition fails and `qty_ordered` remains `None` and it come out of condition
* where it take quantity `'qty_ordered': qty_ordered or quantity,` https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/models/stock_move_line.py#L898
* As a result, *Ordered Quantity* becomes equal to *Delivered Quantity*.
CASE-2
* When validating with *more quantity* than demanded:
* `_action_done` creates an extra move using `_create_extra_move()`: https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/models/stock_move.py#L1936
* The extra move is merged back via `_action_confirm(merge_into=self)`: https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/models/stock_move.py#L1878
* The original move keeps `product_uom_qty = 10` but now has two move lines (10 + 2).
* In `_get_aggregated_product_quantities`: Both move lines share the same `line_key`
- **ML1** → `line_key` not yet in dict → enters [if] https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/models/stock_move_line.py#L880 **ML2** → `line_key` already in dict → enters `else` block https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/models/stock_move_line.py#L901-L903
→ `qty_ordered += 2` → `qty_ordered = 12` ✗ (surplus added to demand)
→ `quantity += 2` → `quantity = 12` ✓
* The `else` branch was designed to aggregate multiple lines of the
same product (e.g. two lot lines). The bug was that it added the
**done qty** of each line to `qty_ordered` unconditionally, causing
the surplus from over-delivery to inflate the ordered quantity.
* After the fix:
* Case 1 (Demand=10, Done=8):
* Ordered = 10, Delivered = 8.
* Case 2 (Demand=10, Done=12):
* Ordered = 10, Delivered = 12.
* NOTE:
Adapt the existing test case `test_kit_packaging_delivery_slip`
to reflect the corrected behavior of delivery validation.
The test was originally introduced in this [commit](https://github.com/odoo/odoo/pull/161920/changes/47da1ec13a2189e826d3b0539e6494e35990ccc1).
Its main objective is to ensure that the Delivery Slip report prints successfully
Previously, when validating a transfer with:
Delivered quantity less than the demanded quantity, No backorder created
the Ordered Quantity was being reduced(24->12) to the delivered quantity.
After the fix, the Ordered Quantity correctly remains equal(24->24) to the original demand.
<details>
<summary>Click here to see the results:</summary>
<p><strong>Before:</strong></p>
<div>
<img src="https://github.com/user-attachments/assets/88d24079-b278-4ef9-bff2-c7f14fe7ecb7" />
<img src="https://github.com/user-attachments/assets/c6181771-7d91-4ffe-9ed8-17dffac346f7" />
</div>
<p><strong>After:</strong></p>
<div>
<img src="https://github.com/user-attachments/assets/6ed57881-8af3-42ad-94d4-7c44a5b9b00e" />
<img src="https://github.com/user-attachments/assets/b5506c81-3ed9-416b-8099-108a75588b13" />
</div>
</details>
---
opw-5874759
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#261612
Forward-Port-Of: odoo/odoo#250587This update resolves an issue where expense card payments were incorrectly rejecting transactions from airlines, car rentals, and hotels due to missing Merchant Category Codes (MCCs). The update adds the necessary MCC ranges to the system, ensuring these expense types can be processed correctly. This improves the functionality of the Stripe expense card.
Original PR description
In the expense card, when a payment is made. The card can be filtered to only allow certains category of merchant. However, the 3 ranges of MCC we not added: - Airlines, air carriers: MCC's from 3000 to 3350 - Car Rental Agencies: MCC's from 3351 to 3500 - Lodging, hotels, motels and resorts: MCC's from 3501 to 3999 And since the MCC are not present in the list, they are rejected by default even the card is set to accept all MCCs. task-5486945 Forward-Port-Of: odoo/enterprise#115379 Forward-Port-Of: odoo/enterprise#114154