Daily updates from Odoo
Wednesday, December 3, 2025
48 changes · master
New functionality added to Odoo
This update introduces a new contingency invoicing feature for Colombia, allowing businesses to continue issuing invoices even if their connection to the DIAN electronic invoicing system is temporarily unavailable. This ensures ongoing tax compliance and maintains accurate customer records, providing a backup solution for invoice processing.
Original PR description
Purpose: Contingency Invoices ensures the continuity of the invoicing process in the event of technical failures, service interruptions, or inability to connect to the DIAN electronic invoicing system. It allows the user to issue valid invoices, ensuring compliance with tax obligations and maintaining commercial traceability. Expected Behavior: For customer invoices, when the user selects the document type to be a contingency, the user will be able to print the contingency invoice report without DIAN information to send to their customers. Once the connection establishes with the DIAN, the user can send the invoice to the DIAN and print a completed invoice with all the information received by the DIAN. task-5091290
This update introduces a new module that allows Odoo to automatically generate websites from e-commerce sites like Shopify. It addresses issues with image cropping and font support, and importantly, enables the integration of product data from external websites into Odoo's product catalog. This streamlines the process of creating and maintaining online storefronts.
Original PR description
This module is used to contact the website scraper server (WSS) with a url to scrape, receive the requested output and use it to generate the corresponding website in odoo. In order for this module to work, two system parameters must be set up: 1) "website_generator.token", a token which is used to identify the user(s) and give the appropriate access to the WSS 2) "website_scraper_endpoint", the public url of the WSS
Enhancements to existing features
This update streamlines the rendering of templates within Odoo Enterprise modules by removing outdated syntax and promoting cleaner, more efficient code. The changes enhance performance and maintainability, ensuring a smoother user experience for Enterprise users. This work addresses inconsistencies and improves the overall structure of the templates.
Original PR description
see community: https://github.com/odoo/odoo/pull/235469 see: https://github.com/odoo/odoo/pull/197296
This update enhances the Odoo Enterprise VoIP system by displaying the last called number when the call button is clicked, even if no numbers are initially entered. This simplifies the dialing process for users and improves the overall user experience. It's a minor improvement focused on usability.
Original PR description
If no numbers are provided, when click on the call button in keypad, we will show the last called number. Task-5225969
This update replaces the specific "Uruware" name in the Odoo settings with a generic "UCFE Provider" label. This ensures customers contact Odoo support for assistance and maintains a consistent configuration for Uruguayan users, streamlining the setup process.
Original PR description
Before: -In the Settings > Uruguay Localization section, electronic invoicing provider was shown as "Uruware". -This could lead customers to contact Uruware directly instead of Odoo support. After: -Replaced all mentions of `Uruware` with generic name, `UCFE Provider`. -Updated labels and descriptions in both testing and production sections. -The overall configuration and functionality remain unchanged. Impact: -Removes direct provider references from the interface. -Ensures customers contact Odoo support for any assistance. -Keeps the configuration clear and consistent for Uruguayan users. task-5244539 Forward-Port-Of: odoo/enterprise#101053 Forward-Port-Of: odoo/enterprise#99065
This update simplifies website creation by grouping options into a dropdown menu for a cleaner user interface. Additionally, the website generator now automatically creates a website immediately upon request, preventing unnecessary and potentially problematic creations. This change improves the overall user experience and reliability of website setup.
Original PR description
Added a new dropdown to group the two options of creating or importing a website into a more elegant UI. Also changed the behavior of the website generator so that it creates the website on reception of the request. This avoids potentially making a useless one in case of an error or the user exiting the view.
This update adapts the US payroll system (l10n_us_hr_payroll) to a new flexible benefits structure based on salary rules, introduced in Odoo 19.0. This change streamlines benefit calculations and aligns with updated payroll regulations for US businesses.
Original PR description
In 19.0 a new system of flexible benefits coming from salary rules was introduced. This commit serves to adapt the l10n for the united states to the new format. task-5122330
This update enhances the user interface for selecting online accounts within the Odoo Enterprise system. The previous radio button component was removed, streamlining the selection process and improving usability. This change focuses on a better user experience for managing online accounts.
Original PR description
This commit refactor the online account selection widget to have a better ui. task-5090281
This update has consolidated salary-related information from the `hr_recruitment_integration_base` module into the `hr_recruitment` module. This change streamlines the recruitment process and improves data organization within Odoo, enhancing the overall user experience.
Original PR description
In this PR we have moved salary related fields from `hr_recruitment_integration_base` to `hr_recruitment` module Task-5212975
This update streamlines email templates across several Odoo modules by utilizing a simplified template structure and optimizing translation handling. The changes remove redundant header and footer elements, improving email performance and reducing complexity. This impacts modules including sale_subscription, documents, and knowledge.
Original PR description
We use encapsulating template wherever it is possible to simplify the email templates (by removing the header and the footer that are now in the generic encapsulating template). To translate the…
We use encapsulating template wherever it is possible to simplify the email templates (by removing the header and the footer that are now in the generic encapsulating template). To translate the subtitles into the recipient language, we use LazyTranslate to defer translation until the recipient’s language is available in context. Notes about sale_subscription: - mail_template_subscription_alert has not been modified as it don't really have a header or a footer but just a frame with a title around the message which don't repeat information of the header or the footer. - To get a simpler header, we use "mail_notification_light" as layout for the mail_template_subscription_rating template (through the email_layout_xmlid field added in odoo/odoo#114462). Note about knowledge: we adapt the code following the replacement of the "subtitles" parameter of the method mail_thread.message_notify method by the context variable "email_notification_subtitles". various: documents, knowledge, payment_sepa_direct_debit, sale_subscription, timesheet_grid Task-2810103
This pull request updates the tests for the documents_spreadsheet module to align with recent code modifications. These changes ensure the tests accurately reflect the current functionality and maintain the stability of the enterprise version of Odoo. This is a routine maintenance update.
Original PR description
This commit adapts tests to changes made in https://github.com/odoo/odoo/pull/237520 task-5355048
This update allows users to search for achievements more efficiently by searching using the name of the related record. This change simplifies finding specific achievements linked to other records, leading to a better user experience and reduced search times. It's a key improvement for sales and reporting workflows.
Original PR description
Before: - Users could not search for achievements using the name of the related record in the achievement search view. After: - Users can now search for achievements using the related record’s name, making it easier and faster to find the desired records. Impact: - Improves user experience in the achievement search view. - Saves time when looking for records linked to specific related items. task-5176601
This update refines the promotion studio functionality within the Enterprise module. By switching to a button tag, the studio dialog is now correctly disabled when the system is offline, preventing unnecessary attempts to open it. This ensures a smoother user experience, particularly for users operating in offline environments.
Original PR description
By using a button tag, the item is properly disabled in offline mode, which is what we want as it doesn't make sense to open the dialog to promote/install studio in that case. Task~5359151
This update significantly speeds up the calculation of complex reports by optimizing how aggregations are processed. The system now intelligently prioritizes calculations based on data availability, reducing processing times from 20 seconds to less than 1 second. This enhancement improves report generation performance and overall system responsiveness.
Original PR description
(aka MAGA: Make Aggregations Great Again) When a report contained many aggregations to evaluate, with complex interdependencies, the way the computation was done was to naïve. This happened with a…
(aka MAGA: Make Aggregations Great Again) When a report contained many aggregations to evaluate, with complex interdependencies, the way the computation was done was to naïve. This happened with a new Japanese report we're currently implementing, which contains multiple sections referencing each other with cross_report aggregations. Basically, we used to make a queue of all aggregations to evaluate, pop the first one, try to evaluate it, and if it was still missing some data, enqueue it back. We kept on looping like that until every formula got evaluated. On the (extreme) case we faced, it took 20 seconds just to compute aggregations on a database with only demo data ! We solve this by rewriting the aggregation engine in such a way that it only tries to evaluate the expressions it has enough data to compute. Essentially, we now keep track of the number of dependencies to other aggregations that still need to be resolved before being able to evalutate a formula, and we only evalute the ones whose associated count is 0. On our test example with the Japanese report on a db with only demo data, the computation of aggregations went from 20 seconds to less than 1 with this commit. To make this refactoring possible, some restrictions needed to be added to cross_report aggregations: 1) By default, a cross_report aggregation does not force its date_scope to the terms it calls anymore. This was only done for Balance Sheets calling the P&L, and induced a LOT of complexity, and the possibility of many unintended corner cases, some of which working purely by chance, some others simply breaking, none of which seeing any actual use in the standard data. I it still possible to force the date_scope for an aggregation really needing to do so, but it needs to be specifically asked in the subformula. The syntax for that is now: cross_report(report_id, force_date_scope). When a cross_report aggregation is to be evaluated without forced date scope, it will use the date scope of each of its terms, just as if all those expressions had been part of the current report. On top of the technical benefits, it's also functionally clearer for the users customizing reports by hand. 2) cross_report aggregations with a forced date_scope do not allow referencing other cross_report aggregations anymore. Doing that would allow for triangle dependencies between reports, and proper propagation of the forced date scopes would require additional complexity that we don't want. We now prevent this with a constraint. None of the standard report needed to be adapted ; if some custom-made report fails because of this change, it's anyway possible to reference directly the expression(s) they want instead of counting on an additional indirection. task-5243334
Resolved issues and error corrections
This update resolves an issue where discount calculations on Mexican global invoices were producing incorrect values, leading to errors. The fix ensures accurate rounding of discount amounts during invoice generation, aligning with Mexican tax regulations. This improves the reliability of invoice creation for our Mexican customers.
Original PR description
Steps to reproduce: ------------------- * Create an invoice with the following line: * Unit price: 47.25, Qty: 1, Taxes: 16%, Discount 50% * Confirm, create a global invoice > Observation: Error ```…
Steps to reproduce: ------------------- * Create an invoice with the following line: * Unit price: 47.25, Qty: 1, Taxes: 16%, Discount 50% * Confirm, create a global invoice > Observation: Error ``` Code : CFDI40108 Message : El TipoDeComprobante es I,E o N, el importe registrado en el campo no es igual al redondeo de la suma de los importes de los conceptos registrados. ``` Why the fix: ------------ The issue occurs because the `descuento` value, originally 23.625, is now being corrected to 23.615 which leads to `importe` having a value of 23.635 which round up to 23.64 and not 23.63. https://github.com/odoo/enterprise/blob/08564f3312c255f2f3ab95cef5a9bfc57727bd1f/l10n_mx_edi/models/l10n_mx_edi_document.py#L1111 https://github.com/odoo/enterprise/blob/08564f3312c255f2f3ab95cef5a9bfc57727bd1f/l10n_mx_edi/models/l10n_mx_edi_document.py#L1336 Before this commit https://github.com/odoo/enterprise/commit/39759babddc732a312ec5cd6a60a2f1819abc62c the discount value was being rounded when corrected. It would end up being evaluated to 23.62. To not bring back the issue the fixed by the mentioned commit we round the discount when generating the global invoice cfdi values. Now `importe` will have a value of 23.63 as `descuento` is rounded to 23.62. opw-5023597 Forward-Port-Of: odoo/enterprise#95982 Forward-Port-Of: odoo/enterprise#94438
This update fixes an issue where Brazilian vendor bills incorrectly applied sales taxes instead of purchase taxes due to a flaw in the external tax calculation. The fix ensures that the correct tax type ('COFINS Incl.' etc.) is used when computing taxes for vendor bills, improving financial accuracy for Brazilian businesses using Odoo.
Original PR description
**Steps to reproduce:** - Install accountant, l10n_br and l10n_br_avatax - Switch to a Brazilian company - In Accounting settings, configure AvaTax (require credentials) - Create a bill - Compute taxes with AvaTax **Issue:** If a tax like "COFINS Incl." should be added, the Sales tax is added instead of the Purchases one, resulting in an incorrect account for the tax line. **Cause:** Brazilian localization allows to use AvaTax for vendor bills, but the external tax feature doesn't take into account the type of the tax when searching for one. It just returns the first one based on the name, the amount and some other domains. **Solution:** Add the tax type in the domain when searching a Brazilian tax. **PR (Community):** https://github.com/odoo/odoo/pull/236930 opw-5044423 Forward-Port-Of: odoo/enterprise#100854 Forward-Port-Of: odoo/enterprise#100340
A technical error was preventing users from correctly adjusting salary benefits within the offer generation process. This update resolves a 'TypeError' that occurred when a specific benefit type ('Always Selected') was present, ensuring the salary package website page functions as intended. This fix improves the user experience for generating salary offers.
Original PR description
Steps to reproduce: 1. Install 'hr_contract_salary_payroll' 2. Create three benefits from Payroll > Configuration > Benefits - Basic: Salary Structure Type: US Employee Contract Related Field: Health…
Steps to reproduce:
1. Install 'hr_contract_salary_payroll'
2. Create three benefits from Payroll > Configuration > Benefits
- Basic:
Salary Structure Type: US Employee
Contract Related Field: Health Benefits Dental
Display Type: Slider (1500, 6000)
- Housing:
Salary Structure Type: US Employee
Contract Related Field: Health Benefits Vision
Display Type: Always Selected
- Transport:
Salary Structure Type: US Employee
Contract Related Field: Health Benefits Vision
Display Type: Manual
Mandatory Benefits: Basic, Housing
3. Go to Employees > Contracts
4. Create a new contract:
Set an employee
Salary Structure Type = US Employee
HR Responsible = Mitchell Admin
5. Click the Generate Offer smart button.
6. Open the link
7. Adjust the sliders
Issue: it gives a traceback
`TypeError: Cannot read properties of undefined (reading 'type')`
Cause:
https://github.com/odoo/enterprise/blob/cc3fe89528a143cff3ab03e1654755c34eaac112/hr_contract_salary/static/src/js/hr_contract_salary.js#L480-L482
In checkInputSelected, the target array is empty when an Always Selected benefit is present, causing an attempt to read target[0].type.
Solution:
Add a guard to check that target is not empty before accessing its elements.
opw-5058994
Forward-Port-Of: odoo/enterprise#94881This update fixes an error that prevented payroll officers from accessing salary offers. The issue stemmed from the module attempting to access candidate information, which required recruitment rights. The fix ensures payroll officers can now open and manage offers without needing these additional permissions.
Original PR description
steps to reproduce: - Install l10n_be_hr_contract_salary - Log in as a payroll officer (without recruitment rights) - Go to Payroll > Contracts > Offers - Open any offer - Notice an 'Access Error' appears: You are not allowed to access 'Candidate' (hr.candidate) records. cause: The module tries to read `employee_id.candidate_id.partner_id` in offer computations. Since payroll officers lack recruitment rights accessing `hr.candidate` triggers an access error. fix: Wrap candidate access in try/except to handle missing permissions. - If accessible, candidate partner data is used as before. - If not accessible, skip without raising an error. This allows payroll officers to open and generate salary offers without requiring recruitment rights. task - 5039712 Forward-Port-Of: odoo/enterprise#100980 Forward-Port-Of: odoo/enterprise#95869
A minor grammatical error in the SEPA Direct Debit payment provider configuration message has been corrected. This ensures consistent and accurate messaging for customers, improving the overall user experience. The change replaces 'an unique' with 'a unique' in the 'Pending Message'.
Original PR description
Currently, a typo appears in the `Pending Message` shown in the SEPA Direct Debit payment provider configuration. **Steps to reproduce:** - Install the `payment_sepa_direct_debit` module. - Navigate…
Currently, a typo appears in the `Pending Message` shown in the SEPA Direct Debit payment provider configuration. **Steps to reproduce:** - Install the `payment_sepa_direct_debit` module. - Navigate to Invoicing > Configuration > Payment Providers > SEPA Direct Debit. - Open the `Messages` tab and observe the `Pending Message`. **Observation:** The message uses "an unique" instead of the grammatically correct "a unique". **Fix:** This commit corrects the message by replacing "an" with "a" at [1]. Before: <img width="1903" height="606" alt="typo_before" src="https://github.com/user-attachments/assets/df4f658b-9f4c-4e68-b8cb-a1bdc2253fc3" /> After: <img width="1900" height="609" alt="typo_after" src="https://github.com/user-attachments/assets/e9192d70-b343-4e4e-9e21-281a93d4d71e" /> [1]: https://github.com/odoo/enterprise/blob/6c3692d85bf1ef7b14d930d9a1ed244cf8aa851b/payment_sepa_direct_debit/data/payment_provider_data.xml#L13 opw-5373274 Forward-Port-Of: odoo/enterprise#100983
This update removes a redundant view used in appointment scheduling that was causing crashes in certain Odoo modules. The change prevents Odoo from incorrectly attempting to use this view, ensuring stability and proper functionality for all appointment-related features. This resolves a technical issue that could impact users.
Original PR description
Remove the extra pos_list view used for calendar_event_list by the pos because Odoo would try to use it by default to all calendar_event_list views and that would cause it to crash for modules which didn't have the view initialized Runbot Error:[234475](https://runbot.odoo.com/odoo/runbot.build.error/234475)
This update resolves an issue where clicking 'Details' on completed signed documents resulted in an error. The fix ensures the correct sign request record is retrieved, allowing users to now seamlessly view the details of signed documents and maintain workflow efficiency.
Original PR description
Version: - saas-18.4 Steps to reproduce: - Open a template that has at least one completed signed request. - Click the Signed Document state button. - See all documents - Click on the detail button Before: - Clicking the Details button on a completed signed document caused a traceback. - This happened because the view was using the record ID from this.props.record.context, which referred to the sign template instead of the sign request, causing incorrect data to be fetched. After: - Use this.props.record.evalContext to retrieve the correct sign request record ID, with this.props.record.context as a fallback. Impact: - Users can now view signed document details without errors, improving workflow continuity and overall usability. task-5253632 Forward-Port-Of: odoo/enterprise#99221
This update addresses inconsistent focus states on buttons, particularly in dark mode, making them easier to see and use. The change standardizes the focus style across the Enterprise module, enhancing user experience and accessibility. This resolves a usability issue reported by users.
Original PR description
The focus states on buttons are inconsistent and sometimes hard to see (eg. darkmode secondary buttons). This PR defines the `focus-ring-*` variables to make the focus state use `o-component-active-border` everywhere. [task-4878272](https://www.odoo.com/web#id=4878272&cids=1&menu_id=4720&action=333&active_id=1695&model=project.task&view_type=form) Community PR: https://github.com/odoo/odoo/pull/235780
This update fixes a reporting issue where the partner filter in the Partner Ledger report wasn't consistently displaying all transactions related to a partner. The fix ensures that both invoices and related operations (like misc entries) are visible when using the filter, improving reporting accuracy and data visibility.
Original PR description
To reproduce: - create an invoice for partner Bernard Gagnant (very important) - reconcile that invoice with a misc operation ; make sure not to set any partner on the receivable line of that entry - Open the Partner Ledger: both the invoice and misc operation appear under "Bernard Gagnant". This is due to a hack in that report and is the intended behavior - Use the partner filter, on top of the report, to only display partner "Bernard Gagnant" ====> The misc operation does not appear anymore. After this fix, if the filter is applied, we will be able to see both the invoice and the misc operation under the partner. task-5150419 Forward-Port-Of: odoo/enterprise#97528
This update fixes a misleading warning that appeared when renewing subscriptions in version 19.0. The change prevents the system from flagging renewal quotes as duplicates, ensuring a smoother process for users. This improves the user experience and avoids unnecessary notifications.
Original PR description
Version: - 19.0 Steps to reproduce: 1. Create a subscription. 2. Set a customer reference 3. Confirm the subscription and create an invoice. 4. Renew the subscription to generate a renewal quote (state '2_renewal'). Issue: A duplicate order warning is displayed when renewing a subscription Solution: Exclude renewal quotes (`subscription_state == '2_renewal'`) from the duplicate order check in `_fetch_duplicate_orders`. This prevents incorrect warnings when creating or opening renewal quotes. taskid-5258963 Forward-Port-Of: odoo/enterprise#99344
This update adds logging to the automated reconciliation process, making it easier to identify and resolve issues when it runs in user environments. Previously, debugging was difficult, but these new loggers provide greater visibility into the process's execution. This improves reliability and reduces troubleshooting time.
Original PR description
For the moment, it's difficult to debug in users databases in the cron and the try auto reconcile. This commit will add some loggers to be more aware of what's going on. task-5358849 Forward-Port-Of: odoo/enterprise#101003 Forward-Port-Of: odoo/enterprise#100601
A bug causing internal server errors when printing audit reports has been resolved. The update ensures the correct PDF export function is used for this specific report type, improving the reliability of the annual report generation process. This prevents errors and ensures accurate report output.
Original PR description
Steps to reproduce: - Go to "Accounting/Review/Audit/Annual Report" and create an Audit Report. - click "Print" -> Internal Server Error This happens when generating the Journal Audit pdf, this report needs to uses the `export_to_pdf` that is defined in its custom handler `account.journal.report.handler`. The solution is to use `dispatch_report_action`, as it will determine which function to use in order to export the pdf for each report. no-task Forward-Port-Of: odoo/enterprise#100949
This update removes outdated configurations that forced specific start dates for reports. Now, users can easily set the correct start date through the standard form view, simplifying the reporting process. This change improves usability and ensures accurate reporting data.
Original PR description
These overrides are useless now that the user can access the return type form view and configure himself the start_date. Overriding _get_start_date_elements should be avoided as much as possible as this is making the field on the form view useless if set. Forward-Port-Of: odoo/enterprise#100728
This update resolves a technical issue that caused a traceback when users clicked the 'Tracks' stat button on an event page. The problem stemmed from missing data fields in the event view. This change ensures a smoother user experience and prevents errors when viewing event tracks.
Original PR description
**How to reproduce:** - Open an event - Click on 'Tracks' stat button **Before this PR:** A traceback occurs. **Technical reason:** Some fields are missing from the view. They were removed here: https://github.com/odoo/enterprise/commit/301f63597b0c21fef16a1941314ac95602c8f01f **After this PR:** No traceback Task-5262404
This update corrects a flaw in the VoIP contact search test. Previously, the test could incorrectly identify matches due to demo data. The fix now ensures the test only uses data created within the test environment, guaranteeing accurate results and preventing misleading test outcomes.
Original PR description
In the test, we suppose to find no phone number matched result when search term length is shorter than `_phone_search_min_length`. However, it can still match `name` or `email` if possible. In this fix, we change the test to only consider the data created in the test, to avoid the wrong result from demo data.
This update allows authorized users to cancel payslips without needing to be accountants. Previously, reversing a payslip required specific accountant group permissions on related account moves. This change simplifies the process and improves usability for users needing to correct payroll data.
Original PR description
As you need to have accountant group on some fields of the account move to be able to reverse it. We need to do it as sudo. Forward-Port-Of: odoo/enterprise#101076
This update enhances the reliability of point-of-sale transactions by automatically retrying failed requests (5xx errors) and ensuring tills remain operational even when the payment processing server is temporarily unavailable. The changes simplify the underlying code and improve error handling, leading to a more stable and dependable POS experience.
Original PR description
In this task: --------------- - Moved the status code handling logic at proper place for all transactions API responses. - Removed the mixed usage of async/await and .then() by async/await totally in all transaction calls to simplify flow and improve readability. - For 5xx errors (e.g., 503), retry once as they occur when the server is unreachable. Print "TSS not reachable" if even after retries followed by exponential backoff logic. - Guarantee tills remain operational and not blocked even if the TSS is unreachable. task:5051693 Forward-Port-Of: odoo/enterprise#101058 Forward-Port-Of: odoo/enterprise#93694
This update clarifies the Pay Run wizard by making the 'Company' field mandatory. Previously, leaving it blank created a misleading impression of generating payslips for all companies. Now, users must select a company for each pay run, ensuring accurate and transparent payroll processing.
Original PR description
In a multi-company environment, leaving the Company field empty in the Pay Run wizard gives the impression that payslips will be generated for all companies, which is misleading for users. In practice, the pay run is created only for the user’s allowed companies, but the optional field causes confusion. This commit: - Make sure that Company field is mandatory in the Pay Run wizard. - add tests for default value to the currently selected company. - Updates the placeholder text from “Visible to all” to “Select a company for this Pay run”. Task-5266945
This update streamlines the HR payroll system by removing unnecessary references to input fields. Previously, values lingered even when other related fields were changed, causing potential upgrade issues. This change enhances stability and simplifies the system's operation.
Original PR description
Currently when setting condition_other_input_id or amount_other_input_id the value stays until changed again, even if we change condition_select or amount_select to another value. In this commit, the reference to an other_input will be removed if we no longer need it. This is done to prevent issues when upgrading for example, where a reference stops a delete_unused when it is not really used. task-5265607
This update resolves a printer blocking issue caused by incorrect handling of reward discounts on receipts. The fix ensures that discounts are applied correctly, regardless of the number of items or reward types, preventing errors and ensuring accurate receipt printing. This improves the reliability of point-of-sale transactions.
Original PR description
This PR fixes the case of printer blocked using reward lines and multiple order lines. To reproduce the issue: - Add a product with reward (for example 10% reward on 50€ , that is 5€) - Add a second product without reward that costs less than 5€ - Print the receipt on fiscal printer The lines are orderer before the non reward lines, than reward lines. The printer is blocking because the adjustmentType discounts last line of less than 5€. It is wrong. Another way to reproduce the issue: - Add a product with reward - Add a second product with reward - The reward line with the sum of both rewards is created The same error appear because it discounts both lines. It is better to discount the entire department instead of the last sale Forward-Port-Of: odoo/enterprise#98699
This update resolves an issue where the AI module was incorrectly handling file content. The changes prevent unnecessary data duplication and ensure consistent checksum calculations, improving the reliability of AI document processing. This is a minor fix focused on internal AI module functionality.
Original PR description
The cron is encoding the `content` to compute its checksum already. Also don't set `index_content`, as far as I can tell it's unconditionally computed by `ir.attachment` on both create and write (via `_set_attachment_data` in the latter case). Forward-Port-Of: odoo/enterprise#100985
This update fixes an issue where changes to fields like insurance or company car didn't correctly update related sub-fields in the employee configuration. The update ensures that these fields always display the most current values, improving the user experience and data accuracy. Additionally, a performance optimization was implemented for a key calculation.
Original PR description
'*' = be, ch purpose: currently when you change the values of fields like insurance or company car the onchange doesn't reflect on the subfields which is the case for cars, insurances, etc. this makes the fields have wrong default values in the configurator - added `_onchange` methods for related fields of `hr_version` in `hr_employee` to call the corresponding `_onchange` in `hr_version` - optimized the method `_compute_l10n_be_mobility_budget_amount` to use binary search instead of linear loop task-id: 5173389 Forward-Port-Of: odoo/enterprise#101077 Forward-Port-Of: odoo/enterprise#97472
This update resolves an issue where our system was interfering with the VoIP library's internal stream management. By directly utilizing the library's remote stream, we've prevented conflicts and ensured more stable VoIP functionality. This change enhances the reliability of our voice communication features.
Original PR description
Before this commit, the remote stream was managed by us: creating the MediaStream object, adding the tracks, stopping them... Because of this, we ended up accidentally overwriting the ontrack handler used by the SIP.js library to manage its internal state After this commit, we directly use the remote stream from the library, preventing unwanted interactions. [Task-5379708](https://www.odoo.com/odoo/project/5778/tasks/5379708)
This update fixes a technical issue that prevented completion notifications within the MRP Work Order module from being translated into different languages. The fix ensures that users receive notifications in their preferred language, improving the overall user experience and localization capabilities. This resolves a previous bug impacting internationalization.
Original PR description
The `_t()` was put around the wrong thing, making the strings never translatable. Followup to: 4403621 Forward-Port-Of: odoo/enterprise#101119
This update fixes an error in the default role name used within the sign module. The incorrect name caused potential issues with role assignments and access control. This change ensures proper functionality and security within the sign process.
Original PR description
task-5358513 Forward-Port-Of: odoo/enterprise#100474
This update fixes a bug in the shop floor component consumption process when tracking by lot. Previously, incorrect quantities were consumed, often resulting in drastically inflated amounts. The fix ensures accurate consumption based on lot quantities, resolving this inconsistency.
Original PR description
**PROBLEM** Component consumption behavior in shop floor is buggy when the component is tracked by lot. When "selecting" a lot to take from, the consumed amount is not correct. (ex, we ask for 50g,…
**PROBLEM** Component consumption behavior in shop floor is buggy when the component is tracked by lot. When "selecting" a lot to take from, the consumed amount is not correct. (ex, we ask for 50g, and it consumes 1000kg). **STEP TO REPRODUCE** 1. create a product. 2. create a bom with: - a component tracked by lot, with kg as product uom, but g as the bom uom. - create a step, during which 50g of the component is consumed. 3. create two lots of the component, with 1kg each. 4. create a MO for the product with the bom. 5. in the shop floor, try consuming the component and select one of the lot as a source. 6. the consumed amount should be 50g, remove the move line created (pencil icon, then remove). 7. recreate the move line, the consume amount will be nonsensical (something like 1 000 000g). **CAUSE** 1. The dialog opened for selecting the lot create a new `stock.quant` record, instead of returning the existing quant for the lot. This quant will have a quantity of 0, impacting the computation we do for the quantity we should take from this quant. 2. The formula for the quantity to take from the quant was : `max(min(remaining_qty, quant.available_quantity), 1)`. The `max(...,1)` doesn't work well when `remaining_qty` is between 0 and 1. For example, when using UoM like we do in the repro steps, `remaining_qty = 50g = 0.05kg`. But instead of taking 50g, because of the max we take 1kg = 1000g. 3. There was a double UoM conversion (`_prepare_move_line_vals` already does the conversion, so we don't need to do it before passing qty_to_take as parameter). opw-5136050 Forward-Port-Of: odoo/enterprise#100913 Forward-Port-Of: odoo/enterprise#97005
This update resolves an issue where the 'Reviewed' button wasn't appearing correctly during bank reconciliation. The fix corrects a data call, ensuring the button is displayed when needed. Additionally, a security check has been added to remove secondary buttons during reconciliation for enhanced stability.
Original PR description
Before this commit, we called the wrong variable to know whether the "Reviewed" button is available or not. It leads to have a no show of this button even when it was needed. This commit also adds a small security check to remove the secondary buttons when the statement is reconciled. no task id Forward-Port-Of: odoo/enterprise#101063
This update corrects a bug that previously prevented users from setting negative completion targets for sales commission plans. Previously, attempting to set a negative target would cause an error. Now, negative targets are allowed, ensuring greater flexibility in commission plan configuration. This resolves a potential issue where accurate commission calculations were impossible.
Original PR description
Before this commit, it was not possible to define negative completion target on the plan. task-5362854 Forward-Port-Of: odoo/enterprise#101095
This update resolves an issue where commas in payment memos for New Zealand EFT files were causing errors and rejected payments. The change removes commas from generated files, ensuring correct formatting and preventing payment processing failures. This ensures accurate EFT file submissions to the BNZ bank.
Original PR description
The EFT file format BNZ is exported as a text file. As such, any commas in the field contents will be treated as a new field, resulting in incorrect formatting and a rejected batch file. This…
The EFT file format BNZ is exported as a text file. As such, any commas in the field contents will be treated as a new field, resulting in incorrect formatting and a rejected batch file. This behavior is due to the Odoo community commit [3082d3b](https://github.com/odoo/odoo/commit/3082d3bd0d7a8b45e647c441ba48adcb84a7a070), which partially reversed an improvement to the group payment memo field. - The original behavior was to concatenate the included invoices with spaces (e.g. 'INV/123 INV/124'). - The improvement replaced this with the batch payment reference (e.g. 'BATCH/IN/002'). - The behavior after 3082d3b is to concatenate the included invoices with a space and a comma (e.g. 'INV/123, INV/124' This commit strips the commas from all generated EFT files, instead of further altering the group payment memo field. It also alters existing unit tests to check that commas are removed from payment memo fields. While a fix that changes the memo generation would resolve some issues, this commit ensures that manually added commas will not cause rejected payments. [Ticket link](https://www.odoo.com/odoo/unassigned-tasks/5099220) opw-5099220 Forward-Port-Of: odoo/enterprise#100670 Forward-Port-Of: odoo/enterprise#98613
A bug in the payment state test has been fixed. The test now correctly reflects the payment state of invoices based on whether the ‘accountant’ module is installed. This ensures consistent invoice tracking across different Odoo configurations.
Original PR description
The `test_bill_state_change_on_payment_state` is throwing an exception. ``` self.assertEqual(payment.invoice_ids.payment_state, 'not_paid') AssertionError: 'paid' != 'not_paid' - paid + not_paid ```…
The `test_bill_state_change_on_payment_state` is throwing an exception. ``` self.assertEqual(payment.invoice_ids.payment_state, 'not_paid') AssertionError: 'paid' != 'not_paid' - paid + not_paid ``` The test was incorrectly expecting invoice `payment_state` to always be `not_paid` when payment is reset to draft, but behavior differs based on whether `accountant` module is installed or not. - With `accountant`: Payment has no move_id (no journal entry created by default), so when drafted, `invoice.matched_payment_ids` filters exclude it, resulting in 'not_paid' state. - Without `accountant`: Payment has move_id (journal entry auto-created) so filter conditions fail (`not p.move_id` is `False`), and invoice stays `paid` due to existing reconciliations in `draft` state. Test was introduced here: https://github.com/odoo/enterprise/pull/100834/commits/402bd85af79fa68fa2cb957d40307edf62f7525c Commits that introduced the behavior change: https://github.com/odoo/odoo/pull/182390/commits/b572fcd78289013f28f11157b1bfbb75c9ea7344 https://github.com/odoo/odoo/blob/57f1053b031f293c6cd8dc8f590dccda4fb3e665/addons/account/models/account_move.py#L1308-L1314 Runbot [link](https://runbot.odoo.com/odoo/error/234573) runbot error: 234573 Forward-Port-Of: odoo/enterprise#101089
This update fixes a reporting issue in the Argentine VAT report by correctly mapping data for exempt sales. Previously, the report incorrectly displayed values for non-exempt sales in the exempt balance column. The change ensures accurate reporting of VAT balances based on whether a sale is exempt or not.
Original PR description
This pull request updates the logic for handling exempt balances in the VAT sales report. The main change is the introduction of a new column mapping for "Monto Neto Exento o No Gravado" and the…
This pull request updates the logic for handling exempt balances in the VAT sales report. The main change is the introduction of a new column mapping for "Monto Neto Exento o No Gravado" and the corresponding handling of exempt and non-exempt balances in the query result processing. These change fixes an issue we encountered when checking the sales CSVs ('Débito' and 'Restitución de débito'). Before this change, the column "Monto Neto Exento o No Gravado" was always filled, even when the operation was not exempt, and in that case it repeated the value of "Monto Neto Gravado".
Here is an example:
<img width="1654" height="187" alt="image" src="https://github.com/user-attachments/assets/578fa197-ab72-4801-b714-9c40ddff4b01" />
The correct behavior should be that for taxed operations, only "Monto Neto Gravado" is filled with the 'balance' value, and for exempt operations only "Monto Neto Exento o No Gravado" should have values.
Here is a screenshot of the 'Debito' CSV after the change:
<img width="1614" height="196" alt="image" src="https://github.com/user-attachments/assets/0a18cbe9-d878-4e37-9bb7-21dc8b5cda72" />
**Summary**
* Changed the column mapping for "Monto Neto Exento o No Gravado" from `balance` to `exempt_balance` in the `columns_map` dictionary in `_vat_simple_build_sale_query`.
* Updated the logic for populating values: added handling for `exempt_balance` and `balance` columns so that only exempt balances are shown in `exempt_balance` and non-exempt balances in `balance`, based on the `is_exempt` flag in the row.
Note: the files created were tested on ARCA environment and they could be uploaded without errors.
Forward-Port-Of: odoo/enterprise#97377This update resolves a technical issue that caused Odoo to crash when users selected multiple boxes within the bank statement attachment previewer. The fix ensures the system correctly handles situations where a page doesn't contain date information, preventing the error and improving stability.
Original PR description
If a group of boxes is selected on the attachment previewer on a page that doesn't contain any date, a crash would occur as `this.boxes['date'][pageNumber]` was undefined. task-none Forward-Port-Of: odoo/enterprise#99549
Code cleanup and technical improvements
This update simplifies the way Odoo interacts with IoT devices by removing an unnecessary layer of code. The shift to the `iot_http` service allows direct access to devices through related models, improving efficiency and reducing complexity. This change enhances the overall system performance.
Original PR description
As we now use the `iot_http` service instead of the `iot_longpolling` one, we don't need to add the `DeviceController` layer on devices. We now directy use the devices from related models.
This update introduces a new feature, Store.FieldList, to enhance how email data is managed within the Enterprise version of Odoo. This allows for more flexible and efficient retrieval of information from email messages, improving the functionality of key modules like sales and customer communication. It's a refactoring effort to modernize the system.
Original PR description
Enterprise counter-part. https://github.com/odoo/odoo/pull/236998 task-4676427 task-4676467 task-4676469 task-4775128