Tuesday, February 24, 2026
44 changes · saas-19.2
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 accuracy of account reconciliation by validating the use of 'integer' and 'fraction' groups within regular expressions. Previously, inconsistencies in these groups could lead to incorrect amount formatting, particularly with formats like CODA files. Now, the system enforces that both groups are present when defined, providing clearer error messages to guide users.
Original PR description
When using a regular expression to extract amounts from a label, especially for formats without a decimal separator (like CODA files), the logic now supports and validates the use of named groups 'integer' and 'fraction'. This commit ensures that: - If 'integer' is defined, 'fraction' must also be present to correctly format the decimal value. - If 'fraction' is defined, 'integer' must be present. - Meaningful UserErrors are thrown to guide the user when one group is missing. Enterprise PR: odoo/enterprise#103630 Task [link](https://www.odoo.com/odoo/project.task/5449413) task-5449413 Forward-Port-Of: odoo/odoo#242750
Resolved issues and error corrections
This update ensures internal users accessing message links within slides are consistently directed to the backend form view, aligning with other portal documents. Previously, internal users were incorrectly redirected to the website page. This change maintains a unified user experience across all portal users.
Original PR description
Since #202555, a message link in slides redirects internal users to the website page if it's published. To ensure consistency with other documents in the portal, this commit redirects internal users to the backend form view of the slides. Portal and public users continue to be redirected to the published website page. Forward-Port-Of: odoo/odoo#249720
Features or functions removed from Odoo
This update removes a legacy feature used to access database information within Odoo.com. Following a migration to a newer API (json2), this API user is no longer needed, streamlining the system. This change ensures optimal performance and reduces potential complexity.
Original PR description
Since odoo.com migrated to 19.0, the json2 API is available and therefore we don't need to provide an API user any more to retrieve the list of databases. 3d09f8e0c67904c824b23117c5622630b6fa0899 removed it from the code and the form view, but left the field on res.config.settings for view backward compatibility. With this commit, we finish the cleanup.
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 update adds a notification to the Odoo interface when a user adds or removes a channel as a favorite. This enhances the user experience by providing immediate feedback on channel management actions, making it easier for users to track and manage their preferred channels within the system. This improves channel organization and streamlines user workflows.
Original PR description
Task-5867464 point 84
This update fixes an issue where work entries created from attendance archives were incorrectly including existing entries on the same day, leading to inaccurate work duration reporting. The change ensures that work entries accurately reflect the correct duration for each date, resolving a potential discrepancy in time tracking.
Original PR description
Current behavior: work entries created from attendance archive "included" existing work entries on the same day, even when they do not overlap in time frame. This happens because the attendance intervals are created from records in self, not all attendances on a given day Expected behavior: work entries should reflect the correct duration for a date. opw-5499002 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#107704
This update fixes a problem that occurred after installing the l10n_lu_hr_payroll module. The 'Payroll: Update data' cron job was failing due to a missing file. The issue was resolved by removing the outdated file reference, ensuring the cron job now runs correctly.
Original PR description
When the ``Payroll: Update data`` cron is executed after installing the ``l10n_lu_hr_payroll`` module, a traceback is raised. Steps to reproduce the error: - Install ``l10n_lu_hr_payroll`` module - Run the ``Payroll: Update data`` cron Traceback: ```py FileNotFoundError: [Errno 2] No such file or directory: '/home/odoo/src/enterprise/saas-19.1/l10n_lu_hr_payroll/data/hr_payslip_input_type_data.xml' ``` In commit [1], ``hr_payslip_input_type_data.xml`` file was removed. However, it is still being referenced in the code below here. https://github.com/odoo/enterprise/blob/4174108cb98a9fd84a012ff9dca81ae322c5f338/l10n_lu_hr_payroll/models/hr_payslip.py#L209 As a result, when the ``Payroll: Update data`` cron runs, the system attempts to update a file that no longer exists, causing a FileNotFoundError. [1]: https://github.com/odoo/enterprise/commit/0fecd57652c8c72a4fb91d44bd0c5d75f621541a sentry-7278209115 Forward-Port-Of: odoo/enterprise#108068
This update simplifies the process of adding the 💯 emoji to Odoo messages by introducing a new, more commonly used shortcode (:100:). Additionally, the emoji picker's empty state message has been updated for clarity. These changes improve the user experience and make it easier to express reactions within Odoo.
Original PR description
Purpose of this PR: Before this PR, the 💯 emoji could only be found using the`:hundred_points:` shortcode, which is less commonly used. This PR adds the `:100:` shortcode to improve discoverability. Additionally, the empty-state helper text in the emoji picker is adjusted from `"No emoji matches your search"` to `"No emojis match your search"` for better wording. task-5873748 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250145 Forward-Port-Of: odoo/odoo#248654
This update fixes an issue where non-sale enabled products were incorrectly appearing in sales orders. The change ensures that only products designated for sale are selectable, preventing errors and improving order accuracy. This resolves a potential data inconsistency.
Original PR description
Steps to produce: --- - Install `sale_renting` and `sale_management` modules. - Go to `Sales > Products > Products`. - Create a product and disable the Sales option (`sale_ok = False`). - Create a…
Steps to produce:
---
- Install `sale_renting` and `sale_management` modules.
- Go to `Sales > Products > Products`.
- Create a product and disable the Sales option (`sale_ok = False`).
- Create a Sales Order and try to add that product.
Issue:
--
- Even though the product is not sale-enabled (`sale_ok = False`), it is still selectable in the Sales Order.
Root cause:
---
- At [1], The issue occurs because `super_domain` was not always included.
- When `order_is_rental` is True, `super_domain + []` happens,
so only `super_domain` is applied.
- But when `order_is_rental` is False, instead of
`super_domain + [('rent_periodicity', '=', False)]`, only
`[('rent_periodicity', '=', False)]` was returned, and
`super_domain` was ignored.
- Because of this, base conditions from `super_domain` like
`sale_ok = True` were not applied.
Solution:
---
- Add parentheses around the conditional expression to ensure proper evaluation order and correct domain construction, so only products with `sale_ok = True` are selectable.
[1] https://github.com/odoo/enterprise/blob/abfde5f253c4c52d3a734ca8dafe6f8ed261cf75/sale_renting/models/sale_order_line.py#L49
opw-5902403
---
Forward-Port-Of: odoo/enterprise#107639This update fixes an issue where Odoo would crash during invoice imports, leading to duplicate invoices being created. The fix ensures that invoices are properly acknowledged even if an import error occurs, preventing this duplication. This improves data integrity and reduces the risk of errors.
Original PR description
When importing invoices, if an error occurs in `_peppol_import_invoice`, Odoo crashes before acknowledging the already created bills. But, since `rollbackable_transaction` is used in `_extend_with_attachments`, the invoice is already committed. Since the acknowledgement is not sent while the invoice is committed, the next `_peppol_get_new_documents` attempt duplicates the invoice. opw-5937044 Forward-Port-Of: odoo/odoo#249842 Forward-Port-Of: odoo/odoo#249521
This update enhances how Odoo extracts amounts from bank statements (like CODA files). It now supports decimal amounts identified through regular expressions, specifically designed for statements that don't use decimal points. This allows for more accurate reconciliation of financial data from various bank statement formats.
Original PR description
Update the reconciliation logic of reco models to support regex patterns using named capture groups 'integer' and 'fraction'. This is specifically designed for cases where bank statement labels (like CODA files) provide amounts in cents i.e continuous string of digits without a decimal separator. The logic now: - Prioritizes 'integer' and 'fraction' named groups if present in the match. - Concatenates these groups with a decimal point to form a valid float. - Falls back to the standard digit extraction logic if named groups are not found. So now if user wants the amount to be extracted in decimal values from label then user needs to add regex which supports two groups 'integer' and 'fraction'. Community PR: odoo/odoo#242750 Task [link](https://www.odoo.com/odoo/project.task/5449413) Task-5449413 Forward-Port-Of: odoo/enterprise#103630
This update fixes a bug where deactivated withholding taxes were still being calculated in payments. The fix ensures that the system no longer includes inactive tax rates, resulting in accurate payment totals. This improves financial reporting and reduces the risk of errors.
Original PR description
# How to reproduce - Install the l10n_ar_withholding module - Pick a Vendor and add a Purchase Withholding tax in the accounting tab - Go into configuration and disable that tax - Create a Vendor Bill with that Vendor - Confirm the bill and create a payment # The problem The deactivated tax is still computed in the payment # Why The function that fetches the withholding taxes does not check if the taxes are active or not # The fix I though of 2 solution : - Add an override to remove the taxes from the Vendor when they are deactivated - Add a filter to the fetch function to check if the taxes are active I chose the 2nd solution as it is the least invasive one. opw-5917257 Forward-Port-Of: odoo/odoo#247831
This update resolves an issue where snippets were unintentionally nested within other snippets, causing unexpected behavior in the website builder. The change prevents snippets like 's_popup' and 's_table_of_content' from being dropped into other snippets, ensuring a more stable and predictable website design experience. This improves the consistency and reliability of the website builder interface.
Original PR description
This commit prevents the following snippets to be dropped inside other snippets like tabs, toc, and more: - s_popup - s_newsletter_subscribe_popup - s_newsletter_benefits_popup - s_tabs - s_table_of_content - s_faq_horizontal task-5439635 Forward-Port-Of: odoo/odoo#242035
This update resolves a crash in the Delivery Slip report when printed in languages other than English. The issue stemmed from the report using English labels for key fields. The fix now correctly targets technical fields, ensuring the report functions smoothly across all supported languages.
Original PR description
Steps to reproduce: 1. Switch the partner language to Spanish. 2. Print the Delivery Slip. 3. The report crashes due to translated XPath anchors. Cause: XPath targeted hardcoded English strings 'Tracking Number' and 'Total Weight'. Solution: Target technical fields o.carrier_tracking_ref and o.shipping_weight instead of text labels. opw-5493498 Forward-Port-Of: odoo/odoo#248679
This update resolves a testing issue that prevented users from validating invoices in the AR VAT module. By using 'sudo()' when writing XML fields, the system now bypasses permission restrictions, ensuring consistent and reliable testing. This improves the overall stability of the AR VAT functionality.
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 resolves an issue where Odoo couldn't reliably print to older printers. By defaulting to 'IPP Everywhere' PPDs for compatible printers, the system now supports a wider range of printer models, ensuring consistent printing functionality. This change primarily affects printers discovered via DNS-SD.
Original PR description
When no `ppd` is available for the cups discovered printer, we now use the IPP Everywhere ppd. We only set it for dnssd printers as printer that only implement socket/lpd could be too old and not compatible with IPP Everywhere. Forward-Port-Of: odoo/odoo#247210
This update resolves an issue where the payroll sheet calculation would fail if there were warnings present. The change allows the payroll sheet to be generated even with warnings, ensuring accurate payroll processing. This improves the reliability of the HR payroll module.
Original PR description
Revert https://github.com/odoo/enterprise/pull/104137 Forward-Port-Of: odoo/enterprise#108340
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 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 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 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 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 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
This update adds a new test to ensure the employee tour feature works correctly. This test was created in response to a previous change that introduced the employee tour functionality. This ensures the feature continues to function as expected and provides a layer of quality assurance.
Original PR description
This commit adds a test for the following related PR: https://github.com/odoo/enterprise/pull/104888 task-5779779 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#244682
This update corrects a restriction preventing HR officers from creating new employees in the Belgian payroll system. The fix utilizes 'sudo' access to correctly read a specific field, allowing authorized users to complete the employee creation process without encountering access errors. This ensures smooth onboarding for new employees in Belgium.
Original PR description
Steps to reproduce: - Install l10n_be_hr_payroll - Have a user with only HR officer rights - Try to create a new employee with that user (in BE) - You have an access error on the field l10n_be_resident_situation The field `l10n_be_resident_situation` has the HR Payroll officer group. This field is used on the inverse of the is_non_resident field, which is accessible to HR officers. This commit fixes the issue by using sudo to read the field's value. task-5779779 Forward-Port-Of: odoo/enterprise#104888
This update resolves an issue where VoIP session tracking was incorrectly identifying sessions due to recent changes in how user sessions are managed. The fix ensures the system correctly searches for sessions in the updated session map, improving the reliability of VoIP functionality. This ensures accurate session tracking for our users.
Original PR description
In this PR: https://github.com/odoo/enterprise/pull/104426 session management was introduced that changed the concept of `mainSession` and `transferSession` in the userAgent. There was a missing cleanup in the function `isInProgress` that is still using the old main and transfer sessions. This commit fixes this bug by searching for the session in the new sessions map.
This update resolves an issue preventing users from sharing document templates with read-only fields. By separating validation logic and removing unnecessary security checks, the system now correctly handles shared template requests, ensuring a smoother user experience. This fix improves the reliability of document sharing workflows.
Original PR description
Currently, attempting to share a document template that contains readonly fields fails. When `_populate_constant_items` calls `_fill` to pre-fill these fields, `_fill` aggressively checks that the request state is 'sent'. Since shared links create requests in the 'shared' state, the transaction crashes. Additionally, `_fill` throws a `UserError` if not called with `sudo`, which inappropriately treats a developer/privilege error as an end-user error. This commit resolves the issue by separating concerns: - Moves the `state == 'sent'` validation out of the `_fill` helper and into `_sign` (the caller responsible for actual user signatures). - Removes the artificial `sudo` check in `_fill`, relying instead on standard ORM Access Errors to block unauthorized database writes. (only in master) Task: 5949263 Forward-Port-Of: odoo/enterprise#107898
This update fixes an issue where the order of selection options in sign templates was being lost after saving. The change ensures that user-defined option sequences are consistently preserved, preventing confusion and ensuring data integrity within sign documents. This improves the user experience and reliability of the sign process.
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#108380 Forward-Port-Of: odoo/enterprise#107175
This update clarifies a confusing error message related to delivery scheduling and lock dates. Previously, a validation error would incorrectly flag deliveries as being in a locked fiscal period. The fix ensures the error message accurately reflects the issue and provides better guidance to users, streamlining the delivery validation process.
Original PR description
A recent improvement task (ID [5065601](https://www.odoo.com/odoo/project.task/5065601)) allows `stock.picking` to backdate deliveries, as long as the `scheduled_date` and `date_done` fields are both…
A recent improvement task (ID [5065601](https://www.odoo.com/odoo/project.task/5065601)) allows `stock.picking` to backdate deliveries, as long as the `scheduled_date` and `date_done` fields are both after the lock date. Related: PR #222169
When validating a `stock.picking` record, the constraint `_check_backdate_allowed()` can fail on a different `stock.picking` record. This is confusing for the end user and makes finding the erroneous `stock.picking` difficult.
## Steps to reproduce.
**setup**:
1. install stock, sale, purchase. Use the demo data.
2. Navigate to Inventory > Configuration > Warehouse and click into the Warehouse for the active company.
3. Select the Routes smart button, then select the Buy route. Ensure that the "Product" option is selected for the Buy route.
4. Navigate to Inventory > Product > Product.
5. Create a test product that is:
1. tracked by quantity (General Information tab)
2. Has a vendor listed (in the Purchases tab)
3. Uses the "buy" route (in the Inventory tab)
4. Has a reordering rule for the Buy route (reordering rules smart button)
6. Do not add any stock for this product.
**reproduction**:
1. Navigate to Sale > Orders.
2. Create and confirm a sale order for the configured product, such that more products will need to be created.
3. Navigate into the delivery order for the sale and set its scheduled date to be December 1st.
4. In Accounting > Accounting > lock dates, set all the lock dates to be December 3rd.
5. Navigate back to the sales order, then use the Purchase order smart button to view the purchase order.
7. Use the Deliveries smart button to view the purchase delivery.
8. Validate the delivery - > Validation error thrown
> You cannot modify the scheduled date of this operation because it falls within a locked fiscal period.
**Solution**: add the name of the stock.picking to the error message & only check the lock date when `date_done` is altered, not `scheduled_date`.
[opw-5428179](https://www.odoo.com/odoo/unassigned-tasks/5428179)
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#247474This 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 XML files, ensuring that all text is displayed in the user's chosen language, matching the behavior of other 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
No description available.