Daily updates from Odoo
Tuesday, February 24, 2026
289 changes
30 changes
New functionality added to Odoo
This update adds the municipalities of Guatemala to Odoo, improving address accuracy and consistency. Previously, only departments were available, now users can select Guatemalan municipalities within the Contacts module, enabling proper address management for Guatemalan businesses. This enhancement aligns with localization efforts and supports compliance requirements.
Original PR description
Impacted versions: - 19.0 Steps to reproduce: 1. Install module l10n_gt 2. Go to Contacts > City field 3. Select country Guatemala Current behavior: - Only departments are available, municipalities are missing. Expected behavior: - Municipalities of Guatemala are available in res.city, linked to their respective departments (res.country.state). - Each municipality includes its zipcode and translation in es_GT. Explanation: This PR extends the localization for Guatemala by adding official municipalities and their zip codes to res.city. It improves consistency with other localizations (e.g. Brazil) and allows proper address management for Guatemalan companies. Forward-Port-Of: odoo/odoo#247719
Enhancements to existing features
This update enhances the depreciation schedule reports within the Enterprise edition of Odoo by automatically including an analytic filter. This allows for more granular tracking of depreciation costs by specific projects or departments, providing better financial insights. The change improves reporting accuracy and supports more detailed cost analysis.
Original PR description
Forward-Port-Of: odoo/enterprise#108334
Resolved issues and error corrections
This update fixes a calculation error in the Belgian payroll module, ensuring that meal vouchers and private car expenses are accurately reflected on payslips. Previously, these amounts were displayed as zero. This change ensures accurate reporting and compliance for Belgian employees.
Original PR description
In this commit, we fixed the data of the existing Belgian structure types by setting the right work entry type as default_work_entry_type_id. Belgian's structure types should have the correct attendance work entry type to consider the meal vouchers and the private car in the benefits and payslip lines Before this change, the belgian payslips will have quantity 0 for meal vouchers and private car. After this change, the belgian payslips will have the correct quantity for both meal vouchers and private car. task-5946425
This update fixes a problem where duplicate loyalty cards were being created when not all loyalty programs applied points to an order. The change ensures that loyalty cards are only created when points are actually earned, reducing unnecessary record creation and improving data efficiency. This addresses an internal issue identified as opw-5405109.
Original PR description
Currently, when you have multiple loyalty program but only 1 applies points on the current order, the other will have a loyalty card created with 0 points. steps to reproduce: ------------------- * Create a loyalty program giving you 1 point per $ on product 1 * Create a loyalty program giving you 1 point per § on product 2 * Make a pos order with just product 1, add a customer * Check the programs in the backend > Observation, a loyalty card with 0 points was create for the second loyalty program Why the fix: ------------ This creates a lot of unecessary records. We now only create cards where there are points or when there 0 points because a reward has been applied, thus keeping history. opw-5405109 Forward-Port-Of: odoo/odoo#248653 Forward-Port-Of: odoo/odoo#244254
This update resolves a technical issue related to the preparation of the Cycle Transportation Declaration for Belgian payroll. The fix ensures accurate reporting of this specific tax requirement, improving compliance with Belgian regulations. This change primarily impacts the l10n_be_hr_payroll module.
Original PR description
Forward-Port-Of: odoo/enterprise#108069
This update fixes an issue where location, notes, and privacy settings weren't being correctly carried over from the quick event creation form to the full event form. The change ensures that all entered information is consistently reflected when editing events, improving data accuracy and user workflow. This was a simple fix to a data loss issue.
Original PR description
Steps to produce: --- - Install `calendar` module. - Go to `Calendar and create a new event using quick create`. - Set Location and Notes and other values. - Click `More options`. Issue: --- - When…
Steps to produce: --- - Install `calendar` module. - Go to `Calendar and create a new event using quick create`. - Set Location and Notes and other values. - Click `More options`. Issue: --- - When the full form view opens, the `Location, Notes and Privacy` fields are empty, even though they were filled in the quick-create dialog. Root cause: --- - At [1], [2] & [3], `Location, Notes and Privacy` values are correctly stored in the location, notes and privacy fields respectively. - When opening the full form, default values are built via `getDefaultValuesFromRecord`. - And here at [4], location,notes and privacy are missing from the `QUICK_CREATE_CALENDAR_EVENT_FIELDS`. - As a result, these fields are skipped and not passed through the context, causing data loss. Solution: --- - Add the location and privacy fields to the `QUICK_CREATE_CALENDAR_EVENT_FIELDS` dictionary so they are included when generating default values for the full form view. - And replace `description` with `notes`. Note: --- - As this is a small and simple case, the test has not been added to avoid unnecessary overhead. [1]: https://github.com/odoo/odoo/blob/7abd7ba2f38fdb1953c39fd3693f012c2ad1b497/addons/calendar/views/calendar_views.xml#L378-L381 [2]: https://github.com/odoo/odoo/blob/7abd7ba2f38fdb1953c39fd3693f012c2ad1b497/addons/calendar/views/calendar_views.xml#L404-L407 [3]: https://github.com/odoo/odoo/blob/7abd7ba2f38fdb1953c39fd3693f012c2ad1b497/addons/calendar/views/calendar_views.xml#L400-L403 [4]: https://github.com/odoo/odoo/blob/7abd7ba2f38fdb1953c39fd3693f012c2ad1b497/addons/calendar/static/src/views/calendar_form/calendar_quick_create.js#L7-L17 opw-5504553 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247117
This update resolves a display issue in the employee offer screen for the Belgium payroll localization. Previously, a contract type field was incorrectly added, which has now been removed. This ensures the correct offer screen is displayed, aligning with the standard Odoo Enterprise experience.
Original PR description
Bug reproduction: Ensure that belgium payroll localization is not installed, go to offer of employee, contract type field is not there. Bug cause: Contract type field does not exist in the model, it was adding to the view by l10n_be_hr_payroll. Bug solution: I added new field contract_type_id to the hr_contract_salary_offer model (to show it on UI). Solved from 17.0 Note: I need to fix after version 19.0, because by starting from 19.0, the Belgium one will try to add the same field to the view again task - 5500488 Forward-Port-Of: odoo/enterprise#108179 Forward-Port-Of: odoo/enterprise#104578
This update fixes an issue where trial website requests were sometimes creating duplicate websites. The changes ensure that new trial websites are always created on the user's existing website, streamlining the trial process. A new, more reliable method for generating websites has also been implemented, eliminating the need for a cron job.
Original PR description
Forward-Port-Of: odoo/enterprise#107320
This update addresses usability issues on the mobile version of the bank reconciliation widget. Specifically, the layout has been adjusted to better accommodate the smaller screen size, and some buttons have been simplified to improve clarity and space efficiency. This enhances the user experience for mobile users.
Original PR description
The mobile style on bank rec widget is a bit buggy, this commit adds few improvements: 1 - When in mobile view, chatter is shown on the right (like in desktop view), but the screen is way too tight to display both chatter and st_lines at the same time. Solution: Display the chatter at the bottom of the screen. 2 - If the screen is too tight to show 2 primary buttons (Example: Set Partner & Set Account), We remove the "Set " on the buttons label to save some space. 3 - In tablet view, we don't have enought place to show all the secondary buttons we are showing in desktop view. This commit removes the reco model secondary buttons. (Now accessible in the dropdown menu) task-5114831 Forward-Port-Of: odoo/enterprise#96103
This update prevents internal Odoo users without invoicing rights from accessing and downloading invoice data in JSON/XML format. Previously, a vulnerability allowed internal users to view these sensitive files, posing a potential security risk. This change ensures that access to this data is restricted to authorized invoicing users, improving data security and compliance.
Original PR description
Steps to reproduce: 1. Create an Invoice 2. Send for EDI (should in error, easy way to do it in local turn off the internet) 3. Turn Debug mode 4. Click Download (A new window with URL with will be open) showing the JSON/XML 5. Change Marc Demo (or any user) being internal user without Invoicing rights 6. That user can access the JSON/XML with that particular URL After this commit- We make sure only Invoicing Users can download the JSON/Export task-5481114 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243257
This update resolves a bug where users without access to a company were unable to view organization charts for employees in that company. The fix ensures that access checks are performed correctly, allowing users to see the full organizational structure regardless of company permissions. This improves usability and prevents data access errors.
Original PR description
## Short functional explanation of the error When an employee A tries to access to the page of another employee B, if that employee has a manager belonging to a company to which employee A doesn't…
## Short functional explanation of the error When an employee A tries to access to the page of another employee B, if that employee has a manager belonging to a company to which employee A doesn't have access, the employee A will see an AccessError, even if employee A can have access to the page of employee B. ## Reproduction Steps 1. Create a second company to your database. Let's call these companies Company A and Company B. 2. Select Company A as your main company, but make sure Company B is also selected. 3. Create an Employee A. 4. Select Company B as tour main company; but make sure Company A is also selected. 5. Create an Employee B who has A as manager. 6. Create Employee C who has B as manager. 7. With a user only having access to Company B, log in and try to access Employee C's page. ### Expected behavior Employee's C page loads correctly. ### Unexpected behavior An access error occurs. ## Origin of the issue A sudo() was missing. __ opw-5910036 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248819 Forward-Port-Of: odoo/odoo#247817
This update restores a key feature in the Point of Sale system – the ability to mark orders as 'trusted.' Previously, this functionality was removed, causing potential issues with order management. This fix ensures that users can correctly designate trusted orders, streamlining the sales process.
Original PR description
The button save and all the logic about trusted orders were removed. This commit puts it back. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#240883 Forward-Port-Of: odoo/odoo#200567
This update adjusts the order of taxes in Odoo's accounting system for India (l10n_in) to prioritize the most frequently used tax rates. This ensures that the correct tax is applied automatically, streamlining the sales and purchase processes and improving accuracy. This change is a bug fix related to tax calculations.
Original PR description
In this commit, we are updating the tax sequence so that the most frequently used taxes appear at the top, while the less frequently used ones remain at the bottom. The following adjustments are applied: Exempt, Nil Rated, and Non-GST Supply (for both Sales and Purchase) 5% GST, 18% GST, 40% GST (for both Sales and Purchase) 5% IGST, 18% IGST, 40% IGST (for both Sales and Purchase) All remaining taxes will retain their existing order. Ref - https://github.com/odoo/odoo/pull/228765#discussion_r2486366588 Task-5408149 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update removes a problematic printing library to significantly improve the stability and reliability of printer functionality within Odoo. While features like QR codes and low-paper warnings are being removed, this change prioritizes a more robust and dependable printing experience.
Original PR description
Enterprise PR: https://github.com/odoo/enterprise/pull/108109 The `python-escpos` library was being used for compatible printers since it allowed easier use of features such as QR codes, as well as…
Enterprise PR: https://github.com/odoo/enterprise/pull/108109 The `python-escpos` library was being used for compatible printers since it allowed easier use of features such as QR codes, as well as letting us query the status of the printer to check if it was e.g. out of paper. However, using this library has complicated the code and caused many reliability problems when using USB printers. In particular, the printer could print garbage and then become stuck until it was restarted. This seems to be due to a multi-threading issue, as the print is interrupted half-way through when the `USBInterface` checks for devices. Since the added value is small compared to the extra maintenance and reliability costs, the `python-escpos` library is being removed in favour just using CUPS for all print jobs, as was the case in 18.0. This means we will no longer have a QR code on the status receipt or a warning when the paper is running low, but these are unimportant compared to reliability. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250141 Forward-Port-Of: odoo/odoo#249819
This update eliminates redundant error messages related to IoT receipt printers. As we no longer collect printer status data, these warnings are no longer generated or displayed. This improves the user experience and reduces unnecessary notifications.
Original PR description
Community PR: https://github.com/odoo/odoo/pull/249819 As we are no longer querying the status of the receipt printer on the IoT box, some of the error messages such as being low on paper will no longer be sent by the IoT. This commit removes the messages in the JS code too. Forward-Port-Of: odoo/enterprise#108336 Forward-Port-Of: odoo/enterprise#108109
This update grants the Invoicing & Banks group within the Odoo Enterprise version access to essential reports, specifically 'Statement Reports'. This enhancement improves reporting capabilities for this group, allowing them to better monitor financial data. This change was made to streamline reporting workflows for key users.
Original PR description
In enterprise, we are allowing the Invoicing & Banks group to have access to basic reports, including 'Statement Reports' task-5925567 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249709 Forward-Port-Of: odoo/odoo#249006
This update resolves an issue where Invoicing and Banks users were unable to access key financial reports. The change restores access rights, allowing these users to view essential reports without encountering errors. This ensures accurate reporting and analysis for these user groups.
Original PR description
* Revert commit https://github.com/odoo/enterprise/commit/86c3c212bb79fbc2becac46f4d83b6f2fc381854 that introduced having Accounting features, menu items, and Account on invoice lines available for Invoicing users. * Allow Invoicing & Banks group to access basic reports * Backport missing access rights to properly open the reports without an access error. task-5925567 Forward-Port-Of: odoo/enterprise#108054 Forward-Port-Of: odoo/enterprise#107654
This update fixes issues with downloading the Activitywatch application, specifically addressing problems with the Windows and Linux versions. The changes ensure users can easily access the correct build for their operating system, improving application setup and functionality.
Original PR description
This PR adds the download link for the Ubuntu build of activitywatch, fixes the windows link, and fixes the platform detection. Forward-Port-Of: odoo/enterprise#108079
A horizontal scrollbar appeared in the messaging menu when hovering over muted notifications. This was caused by a margin on the 'Mark as Read' button overflowing the container when the unread counter was hidden. This update ensures the layout remains stable and prevents the scrollbar from appearing.
Original PR description
**Purpose of this PR:** Hovering over a muted notification in the messaging menu caused a horizontal scrollbar because the `'Mark as Read'` button retained a margin that overflowed the container when the unread counter was hidden. This commit makes the margin conditional on the counter's presence, preventing the layout overflow. task-[5904526](https://www.odoo.com/odoo/project.task/5904526) **Before/After:**   Forward-Port-Of: odoo/odoo#247320
This update resolves an issue where the payment QR code remained visible on the customer display after an order was completed. The fix clears data related to the QR code when the order is finalized, ensuring a cleaner user experience. This improves the customer's checkout process.
Original PR description
Steps: --- - Configure online payment on the POS configuration. - Open a POS session and the customer display. - Add a product and an online payment line. - Validate the order and complete the payment via QR code. Issue: --- - The order is finalized, but the payment QR code remains visible on the customer display. - The QR popup must be closed manually every time. Cause: --- - The customer display popup lifecycle depends on `onlinePaymentData`. - This data was not cleared when the order was finalized. Fix: --- - Clear `onlinePaymentData` when the order is completed. task-5502344 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250102 Forward-Port-Of: odoo/odoo#244991
This update fixes an issue where address information was missing from invoice PDF reports. The change adjusts how template variables are used, ensuring that address details, including information blocks and addresses, are correctly rendered when using the external layout. This ensures accurate and complete invoices are generated.
Original PR description
After the refactoring of the t-set syntax on qweb templates and application of the script, the contact address info stopped rendering due to how now a template level variables are now used. This commit targets to fix the invoice pdf report t-set for 'information_block' and 'address' so that the elements are rendered when the 'external_layout' is rendered. task-5955062 target: saas-19.2 -> master --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures that invoice reports across various localized versions of Odoo (e.g., for Ecuador and Mexico) correctly display updated address information. The change addresses a technical adjustment to the report invoice layout, improving the accuracy and consistency of invoice documents for international clients.
Original PR description
Adapted each localization report invoice inheritance on the changes to address block
This update resolves an issue that prevented the correct download of XML invoices for Italian companies using the l10n_it_edi module. The fix corrects a mismatch in how invoice data is structured, ensuring the XML FatturaPA file can be generated without errors. This ensures Italian businesses can continue to comply with local tax regulations.
Original PR description
When downloading the XML FatturaPA of an invoice in an Italian company, A traceback will generate. Steps to reproduce the error: - Install ``l10n_it_edi`` module with demo data - Switch to IT Company…
When downloading the XML FatturaPA of an invoice in an Italian company, A traceback will generate. Steps to reproduce the error: - Install ``l10n_it_edi`` module with demo data - Switch to IT Company - Create a new invoice > Customer: IT Company > Add a product > Confirm > Send > Send - Actions > Print > XML FatturaPA Traceback: ```py TypeError: string indices must be integers, not 'str' ``` In commit [1], ``_get_invoice_legal_documents`` was updated to return a list instead of a dictionary. However, the ``l10n_it_edi`` module was not adapted accordingly and still returns a dictionary at [2]. If ``_get_invoice_legal_documents`` returns a dictionary instead of a list, the following logic incorrectly iterates over dictionary key which leads to the above traceback. https://github.com/odoo/odoo/blob/a74e7e2fa96a56737e9105f3b54d5db2d9c2dba3/addons/account/controllers/download_docs.py#L24-L26 [1]: https://github.com/odoo/odoo/commit/90dcd6cfe904974dfa077c2d8d9e168a09eeecf9 [2]: https://github.com/odoo/odoo/blob/a74e7e2fa96a56737e9105f3b54d5db2d9c2dba3/addons/l10n_it_edi/models/account_move.py#L399-L403 sentry-7272542156 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249408
This update resolves a technical issue where strict email servers were rejecting Odoo emails due to improperly folded subject headers. By preventing folding and ensuring subjects adhere to RFC standards, we improve email deliverability and avoid frustrating '554 Invalid Subject header' errors. This ensures our email communications are reliably received by users.
Original PR description
…r rejections Yahoo and other strict mail servers reject emails with folded Subject headers containing RFC 2047 encoded-words when the folding occurs at inappropriate positions, resulting in "554…
…r rejections Yahoo and other strict mail servers reject emails with folded Subject headers containing RFC 2047 encoded-words when the folding occurs at inappropriate positions, resulting in "554 Invalid Subject header" errors. The root cause is in Python's stdlib (bpo-144156). In an ideal world we would be fixing the issue there, but experience tells us that they are very slow to fix bugs / merge PRs in the email module, and even when they do they usually don't backport the fixes in the python versions we use. This commit extends the existing IdentificationFieldsNoFoldPolicy to also prevent Subject header folding, keeping long subjects on a single line (up to 998 characters per RFC 5322 "MUST" requirement, from the 98 "SHOULD" limit). Since at it, include the other "user defined" smtp headers: to, from, ... The solution follows the same pattern already established for identification headers (Message-ID, In-Reply-To, References) where Odoo prevents folding to avoid MTAs rewriting these critical headers and breaking email threading. See-also: #243119 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#247057
This update corrects a UI navigation problem in the add snippet dialog, specifically when using languages like Arabic. The snippet order was incorrect due to language direction differences, leading to a confusing user experience. This fix ensures consistent and intuitive navigation for all users regardless of their language settings.
Original PR description
After the accessibility improvement in [9ae02d8], snippets previews within the add snippet dialog are tabable. It reveals an issue with the order of the columns depending on the interface language:…
After the accessibility improvement in [9ae02d8], snippets previews within the add snippet dialog are tabable. It reveals an issue with the order of the columns depending on the interface language: when the backend language and the frontend language are not read in the same direction (RTL / LTR), the frontend language is taken to display the previews (see [f9c77de]). This is the right approach to show the snippets themselves, but the order of the columns should be done according to the backend language, which is the one that gives the instructions for the overall UI. To reproduce: - Set the admin's language to arabic - Clear the cache and refresh your page - Edit and open the add snippet dialog - Navigate with Tab => The 1st focused snippet is in the wrong column compared with the rest of the UI. [9ae02d8]: https://github.com/odoo/odoo/commit/9ae02d80894d4043e49d8e2cad068f8018e6f113 [f9c77de]: https://github.com/odoo/odoo/commit/f9c77de84aa6ea705e5d3f129328fb2199103b9a task-5109547 Forward-Port-Of: odoo/odoo#228414
This update resolves an issue where inactive taxes weren't consistently shown in fiscal position mappings. The change ensures that inactive taxes are correctly displayed in the 'Replaces' field when viewing taxes through the configuration interface or within fiscal position tree views. This improves data accuracy and reporting.
Original PR description
Observed issue: inactive taxes are shown in "Replaces" `original_tax_ids` field if the form view of a tax is opened through "Configuration"->"Taxes", but not shown under "Replaces" in a fiscal position tree view, nor are they shown in the same "Replaces" field of the tax form view when opened from the fiscal position tree view. Cause: the fiscal position link calls `action_open_related_taxes` on partner (path `/account.tax/[id]`), while the "Configuration"->"Taxes" calls `action_tax_form` on tax (path `/taxes/[id]`), which has additional context element `'active_test': False` among others. Solution: adding the context to the fiscal position action produces the desired behavior, but it might break something else as it affects the whole view. task-5917667 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247787
This update resolves an issue where Spanish e-Facturae invoices were generating XML files with excessive decimal places (up to 8), causing validation errors with the Spanish tax authority. The fix ensures that currency amounts are rounded to two decimal places as required by Spanish regulations, improving compliance and preventing invoice rejection.
Original PR description
Steps to reproduce: - Have facturae modules installed - Generate invoice with any amount - Send to Facturae Issue: Resulting XML has 8 digits after the decimal point on several fields, such as unit…
Steps to reproduce: - Have facturae modules installed - Generate invoice with any amount - Send to Facturae Issue: Resulting XML has 8 digits after the decimal point on several fields, such as unit price, gross amount, and total cost. When trying to validate such an XML, this results in validation error: "RCF06001: En facturas emitidas en euros, alguno de los importes de las líneas tiene más de dos decimales (regla 6a del anexo II de la Orden HAP/1650/2015)." According to regulation HAP/1650/2015 [1]: For invoices issued in euros, it will be validated that the total line amounts related to the total cost are numeric and rounded, according to the common rounding method, to two decimal places. This commit introduces dynamic decimal precision: 2 places for EUR and 8 places (the previous default) for other currencies. [1] https://www.boe.es/diario_boe/txt.php?id=BOE-A-2015-8844 Machine translated [BOE-A-2015-8844 (1).pdf](https://github.com/user-attachments/files/25345382/BOE-A-2015-8844.1.pdf) opw-5927356 Forward-Port-Of: odoo/odoo#249674 Forward-Port-Of: odoo/odoo#248882
This update ensures that the names of Ecuadorian localization regimes comply with government requirements for electronic invoicing. The change involves updating the names to match official regulations and adding a mapping field to guarantee consistent Spanish naming conventions for all government-submitted invoices, regardless of user language settings.
Original PR description
[FIX] l10n_ec_edi: fiscal localizations name The name of the regimes for the Ecuadorian localization does not respect the government requirements Steps to reproduce: 1. Install l10n_ec_edi module 2. Go to Settings > Invoicing > Ecuadorian Localization 3. In Electronic Invoicing > Regime, the names of the regimes do not respect government requirements Solution: Change the name of the fiscal localizations to respect the requirements Add a computed field used to map the name of the regime to the technical name of the regime used in SRI documents We write them in Spanish because we always want the name of the regime to be in Spanish in the XML invoice sent to the government, even if the user didn't install any other language. opw-5221871 Forward-Port-Of: odoo/enterprise#105914
Miscellaneous changes
This pull request updates the translations for Odoo 19.2, specifically for the SaaS version. It includes new translations for various languages and regions, ensuring our software is accessible to a wider global audience. These updates are a standard part of our ongoing localization efforts to improve the user experience for international customers.
Original PR description
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This pull request updates the translations for Odoo Enterprise's standard modules, ensuring they align with the 19.2 release. The changes include new translations in various languages and the removal of outdated translation files, improving the user experience for international customers. This work focuses on localization and supports our global customer base.
6 changes
Enhancements to existing features
This update enhances the depreciation schedule reports in the Enterprise version of Odoo by automatically including an analytic filter. This allows for more granular tracking of depreciation costs by specific projects or departments, providing better financial insights. It's an improvement to reporting capabilities.
Original PR description
Forward-Port-Of: odoo/enterprise#108334
Resolved issues and error corrections
This update fixes a bug where empty loyalty cards were created when not all loyalty programs applied points to an order. Now, loyalty cards are only created when points are actually earned, reducing unnecessary record creation and improving data cleanliness. This improves the efficiency of our loyalty program tracking.
Original PR description
Currently, when you have multiple loyalty program but only 1 applies points on the current order, the other will have a loyalty card created with 0 points. steps to reproduce: ------------------- * Create a loyalty program giving you 1 point per $ on product 1 * Create a loyalty program giving you 1 point per § on product 2 * Make a pos order with just product 1, add a customer * Check the programs in the backend > Observation, a loyalty card with 0 points was create for the second loyalty program Why the fix: ------------ This creates a lot of unecessary records. We now only create cards where there are points or when there 0 points because a reward has been applied, thus keeping history. opw-5405109 Forward-Port-Of: odoo/odoo#248653 Forward-Port-Of: odoo/odoo#244254
This update fixes an issue where location, notes, and privacy settings weren't being properly carried over from the quick event creation form to the full event details view. The change ensures that all entered information is accurately reflected when editing events, improving data consistency and user workflow. This was a simple fix to a data loss issue.
Original PR description
Steps to produce: --- - Install `calendar` module. - Go to `Calendar and create a new event using quick create`. - Set Location and Notes and other values. - Click `More options`. Issue: --- - When…
Steps to produce: --- - Install `calendar` module. - Go to `Calendar and create a new event using quick create`. - Set Location and Notes and other values. - Click `More options`. Issue: --- - When the full form view opens, the `Location, Notes and Privacy` fields are empty, even though they were filled in the quick-create dialog. Root cause: --- - At [1], [2] & [3], `Location, Notes and Privacy` values are correctly stored in the location, notes and privacy fields respectively. - When opening the full form, default values are built via `getDefaultValuesFromRecord`. - And here at [4], location,notes and privacy are missing from the `QUICK_CREATE_CALENDAR_EVENT_FIELDS`. - As a result, these fields are skipped and not passed through the context, causing data loss. Solution: --- - Add the location and privacy fields to the `QUICK_CREATE_CALENDAR_EVENT_FIELDS` dictionary so they are included when generating default values for the full form view. - And replace `description` with `notes`. Note: --- - As this is a small and simple case, the test has not been added to avoid unnecessary overhead. [1]: https://github.com/odoo/odoo/blob/7abd7ba2f38fdb1953c39fd3693f012c2ad1b497/addons/calendar/views/calendar_views.xml#L378-L381 [2]: https://github.com/odoo/odoo/blob/7abd7ba2f38fdb1953c39fd3693f012c2ad1b497/addons/calendar/views/calendar_views.xml#L404-L407 [3]: https://github.com/odoo/odoo/blob/7abd7ba2f38fdb1953c39fd3693f012c2ad1b497/addons/calendar/views/calendar_views.xml#L400-L403 [4]: https://github.com/odoo/odoo/blob/7abd7ba2f38fdb1953c39fd3693f012c2ad1b497/addons/calendar/static/src/views/calendar_form/calendar_quick_create.js#L7-L17 opw-5504553 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247117
This update fixes an issue where receipts printed with the l10n_gcc_pos module were displaying English text instead of Arabic. The fix adds Arabic translations to the receipt files, ensuring that all text is displayed in the user's chosen language – mirroring the behavior of other Odoo receipts.
Original PR description
Problem: When printing a receipt in arabic using the l10n_gcc_pos module, some of the text is in English. Cause: Translation is not enabled for the module and the text is written in English only in the receipts XML. Solution: Add the arabic translations of texts to the receipts XML and choose the display language based on the user's language (same behaviour in other receipts). Steps to reproduce: - Install l10n_gcc_pos module - Activate and choose Arabic as the language - Open Point of Sale and validate an order - See how some text (specifically "Tax Invoice" and "Simplified Tax Invoice") are printed in English although the rest of the receipt is printed in Arabic. opw-5501464 Forward-Port-Of: odoo/odoo#245795
This update addresses usability issues in the mobile version of the bank reconciliation widget. Specifically, the layout has been adjusted to better accommodate the smaller screen size, and some secondary buttons have been moved to a dropdown menu to maximize screen space. This enhances the user experience on mobile devices.
Original PR description
The mobile style on bank rec widget is a bit buggy, this commit adds few improvements: 1 - When in mobile view, chatter is shown on the right (like in desktop view), but the screen is way too tight to display both chatter and st_lines at the same time. Solution: Display the chatter at the bottom of the screen. 2 - If the screen is too tight to show 2 primary buttons (Example: Set Partner & Set Account), We remove the "Set " on the buttons label to save some space. 3 - In tablet view, we don't have enought place to show all the secondary buttons we are showing in desktop view. This commit removes the reco model secondary buttons. (Now accessible in the dropdown menu) task-5114831 Forward-Port-Of: odoo/enterprise#96103
This update adds the municipalities of Guatemala to Odoo, resolving a previous limitation where only departments were available. This enhancement ensures correct address data for Guatemalan businesses, aligning with best practices and improving consistency with other localized versions of Odoo.
Original PR description
Impacted versions: - 19.0 Steps to reproduce: 1. Install module l10n_gt 2. Go to Contacts > City field 3. Select country Guatemala Current behavior: - Only departments are available, municipalities are missing. Expected behavior: - Municipalities of Guatemala are available in res.city, linked to their respective departments (res.country.state). - Each municipality includes its zipcode and translation in es_GT. Explanation: This PR extends the localization for Guatemala by adding official municipalities and their zip codes to res.city. It improves consistency with other localizations (e.g. Brazil) and allows proper address management for Guatemalan companies. Forward-Port-Of: odoo/odoo#247719
3 changes
Enhancements to existing features
This update adds tests to ensure payslips accurately reflect employee wage types, considering variations in monthly wage types and overlapping leave requests. These tests cover multiple months and employee contracts, enhancing the reliability of payroll calculations. This improves accuracy and reduces potential errors in payslip generation.
Original PR description
This commit adds tests to the `_compute_l10n_ch_swiss_wage_ids` function to verify **Wage Types** in payslips across multiple months and with different **Monthly Wage Types** defined in an employee’s contract, as well as multiple leave requests occurring in different months. task-5906677 Forward-Port-Of: odoo/enterprise#107802
Resolved issues and error corrections
This update resolves an issue where tests were failing due to how patches were being applied within the Odoo Enterprise system. The team has streamlined the patching process, specifically converting certain patches to instance-level configurations to avoid triggering test detection errors. This enhances the reliability of our test suite.
Original PR description
Otherwise they trip the on-test-side-effect-detector (at least in its current incarnation). Forward-Port-Of: odoo/enterprise#107940 Forward-Port-Of: odoo/enterprise#106948
This update corrects a test case related to how Odoo handles multiple product transfers. Specifically, it now accurately reflects the new behavior where transfers merge into existing ones only when a procurement group is defined. This ensures the quality control process aligns with the latest changes in Odoo's picking and transfer functionality.
Original PR description
Fix the test case to align with the updated picking move merge behavior, where the next transfer merges into an existing one only when a procurement group (group_id) is set TaskID-5242340 Forward-Port-Of: odoo/enterprise#99342
10 changes
Enhancements to existing features
This update adds tests to ensure accurate calculation of wage types on payslips, considering various employee contract settings and leave requests. These tests verify correct processing of monthly wage types and multiple leave periods across different months, enhancing payroll accuracy.
Original PR description
This commit adds tests to the `_compute_l10n_ch_swiss_wage_ids` function to verify **Wage Types** in payslips across multiple months and with different **Monthly Wage Types** defined in an employee’s contract, as well as multiple leave requests occurring in different months. task-5906677 Forward-Port-Of: odoo/enterprise#107802
Resolved issues and error corrections
This update corrects an issue where manually created receipts were incorrectly merged into existing transfers without a procurement group, leading to disorganized workflows. The change ensures that each manual receipt creates its own independent transfer operation, improving order management and reducing errors in multi-step processes.
Original PR description
*: purchase_stock Issue Before This Commit: ====================== In a `multi-step` configuration, while validating a transfer that has no `procurement group`, its next operation (Input → QC →…
*: purchase_stock Issue Before This Commit: ====================== In a `multi-step` configuration, while validating a transfer that has no `procurement group`, its next operation (Input → QC → Stock) is merged into an existing transfer that also lacks a procurement group, even when the transfers are manually created and not generated from a Sales or Purchase Order. This results in unrelated transfers being grouped together. Steps to Reproduce: ====================== - Install the `stock` module. - Configure the warehouse to use `three-step reception`. - Create and validate two receipts for Product A (qty 10) with Vendor A. - `Observation`: the next transfers for both receipts are merged into a single transfer, even though both receipts were created manually and not generated from any same source document like PO/SO. Cause of the Issue: ====================== In the `_search_picking_for_assignation()` method, when no `group_id` is defined on a move, the system still attempts to find an existing picking using the `partner_id`. Additionally, in the `_key_assign_picking()` method, moves without a `group_id` are grouped based on their `partner_id`. As a result, validating multiple manually created receipts sharing the `same vendor` causes them to be incorrectly merged into the `same next transfer`, since they do not share a common procurement group. After this Commit: ====================== The `_search_picking_for_assignation()` method now skips searching for existing pickings when moves lack a `procurement.group`. The `_key_assign_picking()` method groups moves by their `originating picking` instead of the partner, preventing merges between unrelated transfers without a procurement group. This ensures each manual transfer creates its `own next operation` in multi-step routes. Task-ID: 5242340 Forward-Port-Of: odoo/odoo#235423
This update corrects a test case related to how Odoo handles multiple product transfers. The change ensures that transfers now correctly merge with existing ones only when a procurement group is specified, aligning with recent updates to the picking move merge behavior. This ensures accurate tracking of inventory movements.
Original PR description
Fix the test case to align with the updated picking move merge behavior, where the next transfer merges into an existing one only when a procurement group (group_id) is set TaskID-5242340 Forward-Port-Of: odoo/enterprise#99342
This update fixes an issue in the barcode picking interface where users were repeatedly prompted to confirm adding multiple extra products. Now, the confirmation dialog opens only once and dynamically updates with the selected extra products, streamlining the process and reducing user friction. This improves efficiency when picking multiple items using barcodes.
Original PR description
When adding extra products in the barcode picking interface, the confirmation dialog did not handle correctly the scan of multiple extra items. Before: Scanning multiple extra products successively opened (mutex + promise) the dialog multiple times. The user had to confirm/cancel each extra product addition one by one. After: The dialog is now only opened once and updated when scanning multiple extra products before confirming. The user can select/deselect the extra products to add before validating. [opw-5193269](https://www.odoo.com/odoo/project/49/tasks/5193269) Forward-Port-Of: odoo/enterprise#107932 Forward-Port-Of: odoo/enterprise#104932
This update resolves an issue where the onboarding tour incorrectly targeted disabled calendar slots in the yearly calendar. The fix excludes ‘disabled’ weekday cells, ensuring the tour reliably identifies and clicks the first available Thursday, even when the calendar initially renders empty slots (e.g., for January 1st falling on a weekend).
Original PR description
Before, the tour attempted to click the “first Thursday” by selecting the first .fc-day-thu element in the DOM. The yearly calendar sometimes renders an initial “empty”/disabled weekday cell (when Jan 1 is Fri/Sat/Sun), so the first .fc-day-thu can be a disabled slot with no actionable element. That makes firstChild de-facto empty and the tour fails (seen reproducibly when the server date is set to years like 2027/2028, for example). Excluding .fc-day-disabled makes the selector target the first real Thursday cell task-5930501 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248275
This update resolves an issue where scanning packaging barcodes didn't correctly associate with related lots, leading to incorrect inventory tracking. The fix ensures that packaging barcodes accurately link to the correct lots during scanning, improving the accuracy of stock movements.
Original PR description
When scaning a lot after a packaging, the lot won't recognize the packaging and will not work properly ### Steps to reproduce: * In the settings enable packagings * Create a storable product P with…
When scaning a lot after a packaging, the lot won't recognize the packaging and will not work properly ### Steps to reproduce: * In the settings enable packagings * Create a storable product P with Units as uom, a barcode and tracked by lots * Create new lots with barcode for Product P * Inventory > Configuration > Product > Units & Packagings * Click on pack of 6 > Packaging Barcodes > New * Create one for your product with a different barcode * Go to barcode > Operations > eg. internal transfer > New * Scan packaging barcode * Scan one of the lots -> Issue, the lot create a new line, and will not find the packaging ### Observation: When scanning a barcode, it will first try to find a match with existing lines, In our case, it will find a match with the line of the packaging, but since the line is considered as "completed" since there was no expected quantity since we create a new picking: https://github.com/odoo/enterprise/blob/13d815457d47846d5391c9a2dc1ed244ef64b6c4/stock_barcode/static/src/models/barcode_picking_model.js#L1497-L1501 It will erase the line, to avoid to overfill a completed line: https://github.com/odoo/enterprise/blob/13d815457d47846d5391c9a2dc1ed244ef64b6c4/stock_barcode/static/src/models/barcode_model.js#L1459-L1460 and since, it decided to ignore that line, it will not find another lines, and will create a new one : https://github.com/odoo/enterprise/blob/13d815457d47846d5391c9a2dc1ed244ef64b6c4/stock_barcode/static/src/models/barcode_model.js#L1535 Additional Issues ----------------- Issue 1 : When scaning a packaging, lot1, packaging, lot2, all the packagings will be linked to the first lot, which doesn't allow us to scan multiple lots. Issue 2 : When having sublines with different uoms, it will add the quantity without considering the differences in uoms ### Steps to reproduce: * In the settings enable packagings * Create a storable product P with Units as uom, a barcode and tracked by lots * Create new lots with barcode for Product P * Inventory > Configuration > Product > Units & Packagings * Click on pack of 6 > Packaging Barcodes > New * Create one for your product with a different barcode * Create a packaging 2 with barcode for product A * Go to barcode > Operations > eg. internal transfer > New * Scan packaging 1 barcode * Scan one of the lot 1 * Scan packaging 1 * Scan lot 2 -> Issue 1, the packaging 2 will be link to lot 1, it won't be possible to link any packaging to another lot. * Scan packaging 2 -> Issue 2, it create a subline (excpeted), but the sum that appear on the main grouped line is wrong, it doesn't considere the difference in uoms ### Observation: Issue one : When scanning a barcode, it will first try to find a match with existing lines, since the uom is the same it will not be erased by the full line check https://github.com/odoo/enterprise/blob/13d815457d47846d5391c9a2dc1ed244ef64b6c4/stock_barcode/static/src/models/barcode_model.js#L1456-L1460 and since, it found a line, it will just add it's self to the line Issue Two: When creating the group lines it will first calculate the sum of all the quantities: https://github.com/odoo/enterprise/blob/8774388a7b1b2ca2c08c752026ac1a20dbc10347/stock_barcode/static/src/models/barcode_model.js#L248-L254 And after inside of groupSublines it will choose the main line and it's uom and use the previous sum for the total quantity: https://github.com/odoo/enterprise/blob/8774388a7b1b2ca2c08c752026ac1a20dbc10347/stock_barcode/static/src/models/barcode_picking_model.js#L1456-L1461 opw-5189492 opw-5408372 Forward-Port-Of: odoo/enterprise#98701
This update resolves a testing issue that prevented users from validating Arabic VAT invoices. The change uses elevated permissions (sudo) to write necessary files, ensuring the testing environment functions correctly regardless of user access rights. This improves the reliability of our Arabic VAT compliance testing.
Original PR description
This pull request makes a minor update to the `_dummy_afip_validation` method in `account_move.py`, improving its reliability for testing environments. * Testing reliability: The method now uses `sudo()` when writing dummy AFIP fields, ensuring that the operation succeeds even if the current user lacks write permissions. Without this fix, if the user doesn't belong to group "base system", it won't be able to validate invoices in testing environment. <img width="1258" height="454" alt="image" src="https://github.com/user-attachments/assets/522bfd9d-33be-4bcd-a60b-ef4c09a8e0d6" /> Forward-Port-Of: odoo/enterprise#107937
This update corrects a reporting issue with Italian invoices (`l10n_it_edi`) by ensuring the total invoice amount (`ImportoTotaleDocumento`) is always displayed in EUR, as required by Italian tax regulations. This ensures accurate reporting and compliance with government standards.
Original PR description
With an `l10n_it` company: - Create an invoice in a foreign currency and export the XML. In the XML, the field `ImportoTotaleDocumento` is expressed in the invoice currency, while `Divisa` is set to…
With an `l10n_it` company: - Create an invoice in a foreign currency and export the XML. In the XML, the field `ImportoTotaleDocumento` is expressed in the invoice currency, while `Divisa` is set to the company currency. `ImportoTotaleDocumento` must be expressed in EUR, as stated in the following document: https://www.agenziaentrate.gov.it/portale/documents/20143/0/10FAQ+pubblicate+il+19+luglio+2019+(aggiornate+il+1+luglio+2021).pdf/6e8acb34-b7c5-730e-6a39-79c0a296e02b > L'art. 21, comma 2, lettera l) del d.P.R. n. 633/72 specifica che > “aliquota, ammontare dell'imposta e dell'imponibile con arrotondamento al centesimo di euro”. > Conseguentemente, se la fattura è emessa da soggetti residenti o stabiliti il codice da inserire nel campo `<Divisa>` > deve essere obbligatoriamente “EUR”. > Article 21, paragraph 2, letter (l) of Presidential Decree No. 633/72 specifies that > “the tax rate, the amount of the tax, and the taxable amount must be stated with rounding to the euro cent.” > Consequently, if the invoice is issued by resident or established taxpayers, the code to be entered in the `<Divisa>` > field must mandatorily be “EUR”. As a result, we now use the **company currency amount** for the `ImportoTotaleDocumento` field (assuming the company currency is always EUR for `l10n_it`). Ticket [link](https://www.odoo.com/odoo/project.task/5913088) opw-5913088 Forward-Port-Of: odoo/odoo#249272 Forward-Port-Of: odoo/odoo#247537
This update fixes an issue where shipping capacity percentages were inaccurate in batch transfers. The change ensures that each batch's capacity is calculated correctly, providing users with reliable data for planning and managing shipments. This improves the accuracy of inventory tracking and dispatch management.
Original PR description
## Issue Before This PR: The fields `used_weight_percentage` and `used_volume_percentage` in the list view were showing incorrect values. These fields were incorrectly aggregating totals across all…
## Issue Before This PR: The fields `used_weight_percentage` and `used_volume_percentage` in the list view were showing incorrect values. These fields were incorrectly aggregating totals across all batches, as the calculation of `estimated_shipping_weight` and `estimated_shipping_volume` was not handled per batch, resulting in wrong percentages. ## Steps to Reproduce: - install inventory module and enable settings for batch transfers and dispatch management, - add two batch records with vehicles assigned (having weight or volume capacity), and transfers having products with weight or volume defined - Observe different values of weight % or volume %, in form and list view. ## Cause of the Issue: In the method `_compute_estimated_shipping_capacity` the computation loop referenced all records together, causing totals to be shared across batches. ## With This PR: Each batch now computes its own estimated shipping weight and volume correctly, ensuring correct per-batch values consistent with the form view and match what users see when opening individual records. Backport of [commit](https://github.com/odoo/odoo/pull/227166/changes/a709e84d8357a622198a8ac0a0199af9b16f56e7) Forward-Port-Of: odoo/odoo#249239
This update corrects a display issue in the Timesheet app's grid view. Previously, hovering over the total overtime cell showed 'Weekly Overtime' instead of the correct 'Total Overtime'. The fix renames the cell to 'Total Overtime' to accurately reflect overtime calculations across different time periods (day, week, month).
Original PR description
### Issue: When displaying the month in the grid view and hovering the bottom right cell, where the total overtime is displayed, it shows "Weekly overtime". ### Steps to reproduce: - Open Timesheet app - In "My Timesheet", display the grid in day or month - Hover the bottom right cell - It displays "Weekly Overtime" ### Solution: Rename it to "Total overtime" to handle all periods (day, week, month). opw-5502864 Forward-Port-Of: odoo/enterprise#107642
16 changes
Enhancements to existing features
This update improves the performance of the Work Entry Attendance module by adjusting how the system counts queries during work entry generation. Specifically, it addresses a change in the system's logic that now creates work entries for weekend holidays, leading to increased query activity. This ensures the system continues to function efficiently.
Original PR description
This PR updates the expected query count for regenerate_work_entries in the Work Entry Attendance module. Due to the new functionality that creates work entries for weekend holidays, additional queries are now triggered during work entry generation. task-4907728
This update improves the user experience by automatically opening avatar cards when a follower is clicked in the follower list. Previously, users were directed to a partner form view, which was less intuitive. This change streamlines the process of viewing follower information.
Original PR description
The tours are updated to reflect the new behaviour where clicking on a follower opens the avatar card for users instead of the partner form view task-5873738 Forward-Port-Of: odoo/enterprise#107393
This update integrates Odoo's payroll system with the Belgian Joint Committee, ensuring compliance with local regulations. It includes changes to rule parameters and data migration to reflect the Committee's requirements, improving payroll accuracy and reporting for Belgian users.
Original PR description
- add the connection of the Joint Committee on rule parameters - add scalegrid rule parameter - migrate scalegrid BE data Task: 5477497
This pull request enhances the testing framework for Odoo's website rental functionality. Changes include a more efficient test setup using setUpClass, streamlining test execution and reducing redundancy. The updates also address community changes and remove outdated common values, ensuring consistent and reliable rental testing.
This update optimizes the performance of Odoo's Studio view editor by eliminating an unnecessary database query. The change ensures that view information is stored directly within the view's key, leading to faster and more efficient operations. This improves the overall responsiveness of the Studio interface.
Original PR description
Because ir.ui.view.xml_id triggers an additional SQL request, it will be more efficient to have that information in the key field of the view.
This update modifies the company settings wizard within the Odoo Enterprise module. The change shifts the focus to using company-specific data, aligning with best practices. This adjustment could potentially impact module uninstallation processes.
Original PR description
In this commit, we changed the configure company settings wizard view from res.config.settings to res.company All the used fields are related to res.company, this can have side effects during module uninstallation (for example). task-5933795
This update enables businesses to export essential payroll reports for Egypt (EG) – specifically NOSI Form 2 and ETA Form 2 – in Excel format. This allows for easier compliance reporting and data sharing with tax authorities. Users may encounter errors if required fields are missing during the export process.
Original PR description
### AIM:
- This commit introduces a way to export NOSI Form 2 and ETA Form 2 for the
Egypt (EG) country.
### FLOW:
- NOSI Form 2:
- Go to Employee -> Reporting > Egypt NOSI Form2.
- While exporting NOSI Form 2, you may encounter a user error; this indicates
that some required fields are missing.
- To export ETA Form 2:
- Once a payslip is created and confirmed > Payment Report > In the export
format, select ETA Form 2.
- While exporting ETA Form 2, you may encounter warnings or errors on the
payslip; this indicates that certain required or optional fields must be
filled to export ETA Form 2 correctly.
### Key Updates:
- Added support to export NOSI Form 2 and ETA Form 2.
Task: 4510109Resolved issues and error corrections
This update resolves a technical issue identified by the Odoo runbot testing system. The change ensures that work entries accurately reflect planned scheduling slots, preventing failures caused by adjustments to the slot calculation logic. This improves the reliability of the work entry planning feature.
Original PR description
update the test to ensure that workentries match the plannning slots rather than a literal value which will fail if the slot calc change Task: 5705528
This update addresses several issues causing crashes related to tracking functionality within Odoo Enterprise. The team has focused on using accurate date/time data instead of strings, streamlining tests, and resolving a bug related to loop usage in multi-mode environments. These changes enhance the stability and reliability of the helpdesk, payroll, and expense tracking modules.
Original PR description
Forward-Port-Of: odoo/enterprise#108286
This update fixes a bug in the payrun process where clicking 'Continue' on validated steps would incorrectly block access to the next step. The fix corrects a misconfigured context key and ensures the increment logic only executes when the active step matches the stored step, improving the user experience.
Original PR description
Problem --------- If you click on Continue on a future step, it will validate all the previous step. If you click on Continue on a validated step it will not give you back the next step if it's already incremented Solution --------- The context key was wrong. The behavior of the increment was wrong too: the increment should be executed only if the current active step is the same as the stored step. task-5960023
This update enhances the automated process for merging duplicate partner records. Previously, large duplicate groups would cause system crashes. Now, the system processes up to 3 partners daily, distributing larger groups across multiple runs to prevent performance issues and ensure a smoother merging process.
Original PR description
Before this commit, automatic partner merging would crash when trying to merge more than 3 duplicates at once because the base merge wizard enforces a 3-partner safety limit. After this commit, the cron processes only 3 partners per day (2 source + 1 destination), leaving remaining duplicates for subsequent runs. This spreads large merge groups across multiple days. task-5864653
This pull request reverts a recent change to the web_studio UI test suite. The previous modification incorrectly checked for an exact element count of three, rather than verifying that the element appears at least three times. This reversion ensures the test suite accurately reflects the expected behavior of the web_studio feature.
Original PR description
Revert modifications made in https://github.com/odoo/odoo/pull/245680 With that modification, we checked that element is exactly 3 times, But this is not the same to check that the element is at least preset 3 times..
This update streamlines how leave entries are created in the Gantt view. Previously, users could add or replace existing entries, but this has been simplified to only adding new entries. This change aligns with recent updates to attendance work entries and improves the overall user experience.
Original PR description
Before this change, the shortcut behavior field had two options: add and replace allowing leave entries in the Gantt view to either add to or replace existing entries. This change completes a missing part of the Work Entries Apocalypse task. Since attendance work entries are no longer created by default, we no longer need different shortcut behaviors. Work entries should always be added, not replaced. Therefore, the shortcut_behavior field has been removed, and add is now the only behavior. Task-5942542
This update adjusts the layout of rental periods within Sales Orders to align with a recent change in how Sales Order headers are displayed. Moving the rental period field after the commitment date restores proper alignment and ensures a cleaner, more organized Sales Order view for rental agreements. This improves usability and clarity.
Original PR description
Before this commit: The `sale_renting` module inserted the `rental_period` field between `payment_term_id` and `commitment_date`. After the community change moving `commitment_date` to the Sales Order header, the `rental_period` field appeared in between fields. After this commit: Moved the `rental_period` field after `commitment_date` in the Sales Order header. task-5892894 See Also: Community PR:https://github.com/odoo/odoo/pull/246689
This update removes a confusing counter in the 'Logged On' column of grouped VoIP call reports. The change was implemented by hiding the counter using a CSS rule within the specific VoIP call list view. This simplifies the reporting experience for users.
Original PR description
Since [1], grouped VoIP call rows show a counter in the "Logged On" column. Added a scoped class on the VoIP calls list view and a CSS rule to hide that group header counter only in this view. I did not find a native list view parameter or option to disable it. [1]: https://github.com/odoo/enterprise/commit/ab2377ebf7d21c6bcb5fcde0e6e4c105c75c29cd task-5955136
Code cleanup and technical improvements
This update streamlines the testing process for the Documents module by moving tests to run after the initial installation. This change reduces the overall testing time, improving development efficiency. It addresses a historical practice of running tests during installation, which was no longer necessary.
Original PR description
Some tests where running at install by default for historical reasons, this commit moves them post install to speedup testing time.
11 changes
Enhancements to existing features
This update adds tests to ensure accurate calculation of wage types on payslips, considering various employee contract details like monthly wage types and multiple leave requests across different months. These tests strengthen the reliability of the Swiss payroll system by verifying correct wage type assignments.
Original PR description
This commit adds tests to the `_compute_l10n_ch_swiss_wage_ids` function to verify **Wage Types** in payslips across multiple months and with different **Monthly Wage Types** defined in an employee’s contract, as well as multiple leave requests occurring in different months. task-5906677 Forward-Port-Of: odoo/enterprise#107802
Resolved issues and error corrections
This update resolves an issue where users could inadvertently add partners from different companies when working with multiple company setups. Previously, the system didn't properly restrict partner selection, leading to potential data inconsistencies. This fix ensures partners are correctly associated with their respective companies, improving data accuracy and reliability.
Original PR description
Before this commit, it was possible to add a partner that was from another company when multiple companies were selected. task-5941113 Forward-Port-Of: odoo/enterprise#107546
This update corrects a discrepancy in payslip calculations for employees using the private car daily allowance. The daily amount is now rounded to two decimal places, ensuring it precisely matches the 'Quantity × Amount' displayed on payslips. This improves payroll accuracy and reporting.
Original PR description
Round the computed daily private-car salary rule amount to 2 decimals so the displayed per-day value matches Quantity × Amount on payslips. References task-5917569 Forward-Port-Of: odoo/enterprise#107986 Forward-Port-Of: odoo/enterprise#106753
This update resolves a testing issue that prevented users from validating Arabic VAT invoices. The change uses elevated permissions to write necessary files, ensuring the testing environment functions correctly. This improves the reliability of the Arabic VAT module during development and testing.
Original PR description
This pull request makes a minor update to the `_dummy_afip_validation` method in `account_move.py`, improving its reliability for testing environments. * Testing reliability: The method now uses `sudo()` when writing dummy AFIP fields, ensuring that the operation succeeds even if the current user lacks write permissions. Without this fix, if the user doesn't belong to group "base system", it won't be able to validate invoices in testing environment. <img width="1258" height="454" alt="image" src="https://github.com/user-attachments/assets/522bfd9d-33be-4bcd-a60b-ef4c09a8e0d6" /> Forward-Port-Of: odoo/enterprise#107937
This update fixes an issue where the order of selection options in sign templates was being lost. The change ensures that users consistently see their selected options in the order they entered them, improving data accuracy and usability. This was achieved by modifying a core process to preserve the original sequence of selections.
Original PR description
Steps to reproduce: 1. Open a Sign template. 2. Drag a 'Selection' field onto the document. 3. In the popover, type options in a specific order (e.g., Delta, Alpha, Beta). 4. Click save. 5. Re-open or inspect the data 6. observe the order is scrambled based on Database ID. Cause: The Python method used `list(set())` which is an unordered collection, losing the user's input sequence. Furthermore, the final `search().ids` call returned records sorted by primary key (ID) rather than the provided list order. Solution: Replace `set()` with `dict.fromkeys()` to deduplicate while preserving input order. opw-5896373 Forward-Port-Of: odoo/enterprise#107175
This update fixes a critical issue in the employee skills report, ensuring accurate historical tracking of skill progression. The report now provides a comprehensive view of skill evolution across the organization, aggregating average progress for a more reliable organizational metric. This enhancement improves data accuracy and provides better insights into employee skill development.
Original PR description
. Fix & Refactor the Skills Evolution Report to provide an accurate, historical view of skill progression across the emplyees. Key changes include: . Historical Skill Tracking: The report now calculates skill evolution by querying hr_employee_skill for each employee, instead of relying on the previous skill level field (previous_skill_level_id). This ensures historical changes are correctly captured, even for skills added or updated over time. . Average Progress Across Employees: The report now aggregates the average progress of each skill across all active employees, providing a true organizational-level skill evolution metric. task-5106696
This update fixes a validation issue in the self-order point system by aligning its data checks with the standard point-of-sale system. This ensures greater data accuracy and reliability for self-order transactions, reducing potential errors and improving the overall customer experience.
Original PR description
This commit improves the data validation of pos self order by using the same validation as the one used for regular pos order.
This update resolves a previous limitation in offer creation, allowing users to now select both the PDF template and designated signatories when generating offers. Previously, certain offer types couldn't utilize these features, restricting customization options. This enhancement improves the flexibility and professionalism of offer generation within the system.
Original PR description
Before if you created an offer for an employee version and not a contract template or a contract template without a sign template, it was impossible to choose a pdf template or signatories. This commit fixes this issue. Backport of https://github.com/odoo/enterprise/pull/101081 Task-5485397
This update resolves an issue where the holiday attest calculation in the payroll module would fail when employees had multiple leave types allocated. The fix ensures all leave types are correctly accounted for during the calculation, preventing errors and providing accurate holiday attest reports. This improves payroll accuracy and reporting.
Original PR description
Bug : - allocate multiple leave types to an employee - lay off the employee -access the holiday attest wizard and try to compute holiday attest and you'll see a traceback Reason : - time_off_allocated and time_off_taken were expecting to find exactly one line of "Legal Time Off". Receiving multiple caused an Error. Fix : FIxing the logic by taking all the available lines and summing there values. task - 5461268
This update resolves a minor issue where the stock barcode scanning process was occasionally rounding off stock quantities, leading to discrepancies in delivery orders. The fix ensures more accurate stock updates when scanning barcodes, improving order fulfillment precision. This impacts the accuracy of stock levels reported in the system.
Original PR description
To reproduce the issue: - Create a stock quantity of product1 for example of 275.84 kg in PACK1 - Create a delivery order of 3.6 kg - Go to the delivery order on stock barcode - Scan PACK1 - The new line is created as 272.2399999999 Forward-Port-Of: odoo/enterprise#108198 Forward-Port-Of: odoo/enterprise#89300
When printing PDF payslips with incorrect templates, users now receive a helpful traceback instead of a generic error message. This allows administrators to quickly identify and correct issues with document layouts, ensuring accurate payroll reports. This fix enhances the user experience and simplifies troubleshooting.
Original PR description
Currently, when a user tries to print a PDF report with an invalid document layout template, there’s no traceback to show what went wrong. **Steps to produce:** * Install payroll with demo data. *…
Currently, when a user tries to print a PDF report with an invalid document layout template, there’s no traceback to show what went wrong. **Steps to produce:** * Install payroll with demo data. * Settings > Configure Document Layout then Edit Layout * Add non-existent field `<div t-if='o.no'/>` * Payroll > All payslips > print any payslip **Observed Behavior:** * Currently it only shows the error in [1], with no context or traceback to explain what went wrong. **Root cause:** * This happens because the route doesn’t include the website parameter. Without it, the system treats the route as non–front end [2], so the error handler never reaches [3].That means [4] never loads the templates [5], and the browser just gets a plain response at [6]. **Solution:** * Catching and raising UserError shows appropriate traceback. **Before:** <img width="1601" height="507" alt="image" src="https://github.com/user-attachments/assets/f7f208f0-cdd7-410e-87e7-32a9651df9d8" /> **After:** <img width="1847" height="928" alt="image" src="https://github.com/user-attachments/assets/c73522d6-2632-422b-b1d1-234e6c61ed2e" /> [1]: https://drive.google.com/file/d/1qJLkFGw4bEclqKihdUI-4bjJofdFArEc/view?usp=sharing [2]: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L386 [3]: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L611 [4]: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L573-L576 [5]: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/views/http_routing_template.xml#L139 [6]: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L575 Related:https://github.com/odoo/odoo/pull/237262 opw-5167898 Forward-Port-Of: odoo/enterprise#100142
13 changes
Enhancements to existing features
This update enhances the Odoo profiling tool by automatically tracking the time taken for database queries. Previously, profiling data was incomplete. Now, the system captures query execution times with a time limit, providing more accurate performance insights for developers to identify and address slow queries.
Original PR description
Modify the query collector so that it add an entry before the query runs and updates the time after it runs. use the async collector periodic sampling to commit the profiler after a time limit. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#215034
Resolved issues and error corrections
This update ensures that disabled user accounts are no longer incorrectly flagged as blacklisted when checking email communication. Previously, disabled users would trigger a blacklist alert, which has now been resolved. This improves the reliability of our email filtering and prevents unnecessary disruptions for users.
Original PR description
When computing wether the user is blacklisted, disabled records must be ignored. https://www.loom.com/share/41ea437477f8416f8b50f9ef979d82bf --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr @moduon MT-13153 OPW-5952301
This update introduces a mechanism to ensure data consistency during API calls, preventing potential conflicts when multiple users access the same records. The `_critical_section` context manager guarantees a snapshot of the database is used, avoiding errors and ensuring reliable operation. This improves the stability and accuracy of our invoicing process.
Original PR description
### The problem Suppose we have two users, A and B, who are on the same account.move and click the same button to make the same API call. Suppose B clicks their button just a bit before A's…
### The problem Suppose we have two users, A and B, who are on the same account.move and click the same button to make the same API call. Suppose B clicks their button just a bit before A's transaction commits. This is what the transactions might look like: 1. A clicks on the button, so the transaction starts... 2. A checks whether the move can be sent -> it can! 3. A acquires a lock on the account.move 4. A does the API call 5. A writes on the account.move At some point between 1 and 5, B starts their transaction: 6. B clicks on the button, so the transaction starts... Then, A commits the transaction: 7. A commits the transaction -> the lock is removed! Then: 8. B checks whether the move can be sent -> it can because B is working on an outdated snapshot of the DB. 9. B acquires a lock on the account.move -> no problem! 10. B does the API call -> no problem! 11. B writes on the account.move -> now there might be a SerializationError. But in the meantime, both A and B performed a non-idempotent external API call... ### Analysis The biggest problem is that when B checked whether the move could be sent, it wasn't working on an up-to-date snapshot of the DB. Another problem is that when B checked whether the move could be sent, it didn't yet have a lock acquired on the account.move. ### Solution We introduce a `_critical_section` context manager that ensures that: - only one database session can enter this context manager at a time for the given records (thanks to a lock); - when you enter this context manager you automatically get an up-to-date snapshot of the DB (thanks to an env.cr.commit) - committing is forbidden within this context manager (to ensure you don't lose the lock). ### How to use this context manager: - Enter it right before you check whether the API call should be made (e.g. checking whether the API was already called). - Exit it after you have written the state resulting from the API call. task-none
This update resolves a discrepancy in the calculation of CFDI invoice amounts for Mexican companies using USD transactions with Quadrum. The fix adjusts the invoice amount to precisely match the calculated MXN value, ensuring accurate reporting and compliance. This addresses a rounding issue that was impacting invoice generation.
Original PR description
Steps to reproduce: (thanks to TBS for investigating + writing the test) 1. Have a MX company with Quadrum 2. Create a USD bank transaction with `13220.00 USD` and `305147.51 MXN` 3. Create a USD…
Steps to reproduce: (thanks to TBS for investigating + writing the test) 1. Have a MX company with Quadrum 2. Create a USD bank transaction with `13220.00 USD` and `305147.51 MXN` 3. Create a USD invoice for `13220.00 USD` and send CFDI 4. Reconcile transaction and invoice 5. Click "Update payments" on the invoice => CRP20211 Looks like it comes from this rounding difference Rate is computed by odoo using `305147.51 MXN / 13220.0 USD = 23.082262481 ≃ 23.082262 MXN/USD` PAC verify the amount paid using `13220.0 USD * 23.082262 MXN/USD = 305147.50 MXN` which is not `305147.51 MXN` Solution: There is no solution by adapting the rate: - quadrum restricts the rate to 6 decimals; - rounding the rate differently (e.g. to `23.082263`) would not help because `13220.0 USD * 23.082263 MXN/USD = 305147.52 MXN` which again is not `305147.51 MXN`. So, the only solution that I can think of is to adapt the amount in company currency so that it is exactly `round(amount_in_payment_curr / rate_rounded_to_6_decimals)`, i.e. in the example, change it to `305147.50 MXN`. In tests, Quadrum seems to accept this. We don't perform the modification for other PACs. opw-4222310
This update fixes a potential issue where the system might attempt to send the same CFDI invoice multiple times. A new safeguard ensures a consistent database snapshot is used before checking if a CFDI can be sent, preventing redundant transmissions and improving efficiency. This ensures accurate invoice processing.
Original PR description
We use the new `_critical_section` helper to ensure that we always have an up-to-date snapshot of the DB when checking whether a CFDI can be sent. This should avoid sending the same CFDI multiple times from different requests. task-none
This update fixes an issue where the number of valid holiday allocations wasn't accurately displayed when a holiday allocation started in the previous year. The fix ensures the smart button on the time off type page correctly reflects the total number of valid allocations, regardless of their start date, improving data consistency and reporting.
Original PR description
__ ## Short functional explanation of the error When setting the start date for a time off allocation to the previous year, it is not taken into account when computing the count of employee…
__ ## Short functional explanation of the error When setting the start date for a time off allocation to the previous year, it is not taken into account when computing the count of employee allocations on the time off type page. ## Reproduction Steps 1. Go to Time off > Configuration > Time off Types and click on any time off type. 2. A smart button Allocations should appear with a number in it. Note the number and click on the button. 3. If no allocation exists yet, create one. Otherwise, click on an already existing allocation. 4. Set the start date of the validity period to any date last year. Set the ending date so that the allocation is still valid as of now. 5. Go back to the Time off type page and look at the number on the Allocations smart button. ### Expected behavior As the allocation we set is still valid, the number shouldn't have changed. ### Unexpected behavior The allocation number has been decreased. However, when we click on the smart button, the same number of valid allocations will show. This creates an inconsistency between the smart button and the allocation page, as the smart button should show the number of valid allocations, and when landing on the allocation page, the results are automatically filtered by validity. ## Origin of the issue The domain of the allocations to take into account when computing the count of valid allocations is defined here: https://github.com/odoo/odoo/blob/2264f330859b79010b227e3a9fda1075de8ed4e8/addons/hr_holidays/models/hr_leave_type.py#L297-L304 This doesn't take into account valid allocations that started during the previous year. The inconsistency with the allocation page can be seen here: https://github.com/odoo/odoo/blob/2264f330859b79010b227e3a9fda1075de8ed4e8/addons/hr_holidays/views/hr_leave_allocation_views.xml#L40-L46 Where the filter is defined based on today, rather than on the whole year, unlike above. __ opw-5504272
This update resolves a crash in the HTML Editor component caused by overly aggressive sanitization of attributes. The fix involves a simple encoding/decoding process to ensure data stored in the editor's embedded components remains intact, preventing unexpected errors. This improves stability and reliability of the editor.
Original PR description
Prior to this commit, since DOMPurify v3.1.2 (and more precisely since usage of v3.1.5 in Odoo), the JS sanitization process aggressively removes html attributes with `-->`, `<style` and `<title` for…
Prior to this commit, since DOMPurify v3.1.2 (and more precisely since usage of v3.1.5 in Odoo), the JS sanitization process aggressively removes html attributes with `-->`, `<style` and `<title` for security reasons (see [1]). However `html_editor` embedded components use `data-attributes` (`data-embedded-props` and `data-embedded-state`) to store various kind of data as a JSON string. Obviously, such JSON strings easily match the DOMPurify regex and these attributes are therefore removed, which results in an Editor crash. There are multiple reasons why such values are acceptable as is for the `html_editor` usage: - only `HTMLElement` instances are sanitized, never a string, therefore there is no `DOMParser` to trick with invalid HTML. - values in these attributes are always/exclusively parsed as JSON strings, and the editor will crash if the value is not a legit JSON. - values in these attributes are HTML escaped by the python sanitizer when the serialized html is sent to the server. - values in the JSON parsed object are at worst rendered as plain text (never as HTML or other parsed formats). - values in the JSON parsed object are never executed as JS (only serializable primitives are stored). Therefore, the suggested solution is to encode the values during sanitization, and decode just after, to keep the rest of the codebase simple and explicit. [1]: https://mizu.re/post/exploring-the-dompurify-library-hunting-for-misconfigurations#dompurify-gt-3.1.2-safe-for-xml task-5960707
This update resolves an issue where products weren't automatically marked as 'published' on the website when assigned to a category. The fix ensures that the product's website visibility is correctly updated during the save process, preventing products from being incorrectly hidden. This improves the user experience for product listings.
Original PR description
Error: AssertionError: False is not true self.assertTrue(product.website_published) Cause: Commit https://github.com/odoo/odoo/commit/ca198cfc7c41a8c15b2734518016007aa1c16457 relies on _onchange_public_categ_ids to set website_published=True when a category is assigned. Two issues: 1. website_published was not in the dialog form view, so its onchange value was never tracked or sent to the server on save. 2. The tour clicks Save before the onchange response is received, so the product is saved without website_published=True. Fix: - Add website_published as an invisible field in the dialog form view so its value is tracked and sent on save. - Wait for the category badge to appear before submitting, ensuring the onchange has completed before save. runbot-237976
This pull request addresses several stability issues within the Hoot testing framework. It includes fixes for test logging, error reporting, and ensures proper cleanup of test environments, ultimately improving the reliability of our automated tests. These changes are focused on enhancing the testing process itself.
Original PR description
Fixes for tests and testing framework. See commit messages for details. Enterprise: https://github.com/odoo/enterprise/pull/107286 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a technical issue preventing Hoot (Odoo's accessibility feature) from correctly responding to user interactions. The fix ensures keydown events are applied to the intended active element, improving the usability of Hoot for users with disabilities. This ensures a smoother and more reliable experience for all users.
Original PR description
Adapt tests failing due to keydown events being applied to the current active element. Community: https://github.com/odoo/odoo/pull/247137
This update enhances the reliability of self-order transactions within Odoo Point of Sale. By aligning the data validation rules with standard POS orders, the system now catches more errors and ensures data accuracy. This improves the overall customer experience and reduces potential issues with self-order processing.
Original PR description
*: pos_online_payment_self_order, pos_restaurant, pos_self_order This commit improves the data validation of pos self order by using the same validation as the one used for regular pos order.
This update fixes a validation issue in the self-order point of sale module. By aligning the data validation rules with those used for standard point of sale orders, we've enhanced data accuracy and reliability. This ensures consistent and trustworthy order processing.
Original PR description
This commit improves the data validation of pos self order by using the same validation as the one used for regular pos order.
Documentation and clarification updates
This pull request includes a signature confirming the completion of a Contributor License Agreement (CLA). This ensures that the code changes comply with Odoo's licensing terms and that the contributor has granted the necessary permissions. The change is a standard legal update and does not impact Odoo's functionality.
Original PR description
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
11 changes
Enhancements to existing features
This update adds tests to ensure accurate calculation of Swiss payroll payslips. Specifically, it verifies the correct handling of different wage types and monthly wage types defined for employees, alongside multiple leave requests across various months. This improves the reliability of payroll reporting in the Odoo Enterprise system.
Original PR description
This commit adds tests to the `_compute_l10n_ch_swiss_wage_ids` function to verify **Wage Types** in payslips across multiple months and with different **Monthly Wage Types** defined in an employee’s contract, as well as multiple leave requests occurring in different months. task-5906677
Resolved issues and error corrections
This update resolves an issue where manufacturing orders created with complex BoMs would fail due to mismatched UoM settings. The fix ensures that stock movements accurately reflect the BoM's UoM specifications, preventing errors and improving the reliability of barcode-based manufacturing processes. This change corrects a previous bug related to BoM and product UoM discrepancies.
Original PR description
Previous behaviour: * Traceback if MO created with a BoM whose lines have UoMs that don't correspond to those of the products, then UoM setting disabled and MO viewed in the barcode app. * BoM line UoMs ignored in favour of product UoMs when creating MO in the barcode app. New behaviour: * No traceback. * Stock moves in MOs properly created with the corresponding BoM line UoMs. Task ID: [4674196](https://www.odoo.com/odoo/my-tasks/4674196)
This update fixes an issue within the departure wizard by switching to a more reliable method for archiving employees. Previously, using 'toggle_active' caused problems; now, 'action_archive' ensures employees are properly removed from the system. This change aligns with a related enterprise issue and improves data integrity.
Original PR description
When archiving an employee from the departure wizard, use the action_archive method instead of toggle_active. Related to odoo/enterprise#100437 task: 5354002
This update fixes a problem where employees marked as archived would still have incorrect appraisal dates, causing conflicts when managing appraisal plans. The change ensures that archived employee appraisal dates are cleared, preventing these errors and improving the accuracy of appraisal settings.
Original PR description
**Steps to reproduce:** Based on this feedback https://www.odoo.com/odoo/project.task/5270281 companies with archived employees face an issue when they try to toggle Appraisals Plans from Appraisls -> Configuration -> Settings -> Appraisals Plans **Issue:** The propblem is that when employees with next appraisal date are archived, their next appraisal date is not cleared which leads to past date conflicts upon trying to set the next appraisals dates for all the employees (which is done through toggling the Appraisals Plans checkbox) **Solution:** - Unset the next appraisal date upon archiving an employee - exclude archived employees from _compute_next_appraisal_date method Task: 5354002
This update corrects a bug where invoices created by users in timezones before Saudi Arabia could be incorrectly dated in the future, leading to rejection by ZATCA. The change ensures invoice dates are properly aligned with Saudi Arabian time, preventing future invoicing issues and maintaining compliance.
Original PR description
In odoo/odoo#236865 we decided to allow clients to backdate invoices by letting them use the `invoice_date` field for the invoice date and use the current time as the issue time because we are not supposed to use a dummy value for time. This created an issue where if a user in a timezone before SA tries to invoice a document around midnight using the current date in SA the datetime created will be in the future which will lead to the invoice being rejected by ZATCA. This commit makes sure we normalize the selected date wrt to the current datetime in saudi arabia so that we never accidentally invoice into the future. task-5890423 opw-5373067 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a labeling error in Odoo invoices for Qatar. Previously, the invoice amount description used "Rial" instead of the correct "Riyal". This change ensures accurate currency representation for Qatar-based accounting, improving data clarity and compliance.
Original PR description
Steps to reproduce: 1- Install Accounting and 'l10n_qa' modules 2- Switch to Qatar company and enable "Total amount of invoice in letters" under accounting settings 3. Issue an invoice and preview it The issue: The description of the amount uses "Rial" Expected behavior: The amount should use "Riyal" opw-5919587
This update fixes an issue where sales order statuses were displayed in an incorrect alphabetical order within the sales Kanban view. The change ensures that statuses appear in the correct, logical order (Cancelled, Quotation, Sale Order, Quotation Sent), improving the user experience and data clarity. This was a minor visual inconsistency.
Original PR description
Steps to produce: --- - Install sales module. - Open sales module > orders > switch to kanban view. - Then make it group by status. Observation: --- - The order of status is not proper. - It comes as…
Steps to produce: --- - Install sales module. - Open sales module > orders > switch to kanban view. - Then make it group by status. Observation: --- - The order of status is not proper. - It comes as Cancelled, Quatation, Sale order, Quatation sent. Root cause: --- - When we perform Group By > Status, the method `web_read_group()` is executed. then in chain `_web_read_group()` calls `read_group()` without providing any explicit `orderby`. Inside `read_group()`, if orderby is not provided, it sets the order to the grouped field itself. - Inside `_read_group()`, the SQL query constructed with an order by clause on the grouped field (state). Therefore, the values are retrieved in alphabetical order as `cancel, draft, sale, sent`. Solution: --- - Define `group_expand` on the `state` field. During `read_group()`, `_read_group_fill_results()` calls this method and reorders the groups accordingly. - This overrides the alphabetical SQL order returned by `_read_group()` and ensures the correct logical status order in Kanban view. opw-5497664 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a problem with how leave periods are tracked, specifically related to time zone differences. By updating the system to use 'request_date_from' and 'request_date_to' instead of 'date_from' and 'date_to', the system now accurately reflects leave interruptions, ensuring correct payroll calculations.
Original PR description
This commit fixes the leaves work interruption constraint by replacing `date_from` and `date_to` with `request_date_from` and `request_date_to`, resolving any inconsistencies that may arise due to time zone differences. task-5966780
This update fixes an error in how project budget spending was calculated, leading to incorrect percentage displays. The fix ensures that negative expense budgets are handled properly, accurately reflecting spent amounts and remaining balances. This improves the accuracy of project cost tracking.
Original PR description
Steps to reproduce: --------------------------- 1. Install the `project_account_budget` and `account_accountant` modules. 2. Create a new project and add an Analytic Account for it from the settings…
Steps to reproduce: --------------------------- 1. Install the `project_account_budget` and `account_accountant` modules. 2. Create a new project and add an Analytic Account for it from the settings page 3. Open the Project Kanban, click the three dots on the project card, and select Project's Updates. 4. Click Add Budget button and open the budget wizard. 5. Add a budget line in the wizard with a planned amount expressed as a negative value for an expense (for example: -10000). 6. Create a Vendor Bill using the same analytic account with an amount of 1000. 5. Confirm the bill. 6. Go back to Project's Updates and click New button to view the budget summary. Observation: --------------------------- The budget summary displays incorrect signs and percentages in Activities summary, for example: ``` -10.0% (-1,000.00) of the -10,000.00 budget has been spent. 110.0% (-11,000.00) of the budget is remaining. ``` This incorrectly shows -10% spent and 110% remaining instead of 10% spent and 90% remaining (-9,000). Issue: --------------------------- The project cost (already negative) was negated again when computing the spent amount in https://github.com/odoo/enterprise/blob/ac3f333d97eda5c86a0813490ac6204d4ec5721f/project_account_budget/models/project_update.py#L16 Double-negating the cost makes it positive, which then gets added to the expense budget instead of reducing it, producing inverted percentages and signs. Solution: --------------------------- For expense budgets (negative budgets), do not apply an extra negative sign when calculating the project cost so the spent, remaining, and percentage values are computed correctly. After the fix: ``` 10.0% ($ 1,000.00) of the $ -10,000.00 budget has been spent. 90.0% ($ -9,000.00) of the budget is remaining. ``` opw-5357854
A test was failing due to access restrictions when dealing with archived company subscriptions. This update uses `sudo` to ensure the test user has the necessary permissions, resolving the error and maintaining proper subscription functionality. This ensures the subscription test suite continues to run reliably.
Original PR description
Following https://github.com/odoo/odoo/commit/6b7b83449739932aa8420ef8fcd888116e3c0f8a, the test was failing because of an access error
` AccessError(_("Access to unauthorized or invalid companies."))`
Fix: use `sudo` to avoid access errors due to the user no longer
having access to the archived company after its archival.
runbot-238373Code cleanup and technical improvements
This pull request streamlines the management of our internationalization (I18n) files by re-exporting the ‘base.pot’ file. Previously, this file was not readily accessible for translation updates, leading to potential delays. Now, it’s more easily available for translators to contribute to our global support for different languages.
Original PR description
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