Tuesday, February 24, 2026
36 changes · saas-19.1
Resolved issues and error corrections
This update resolves a problem where products weren't loading correctly when switching between companies within the Point of Sale (POS) loyalty system. The fix prevents errors that occurred when trying to load products directly, ensuring all products are accessible regardless of the company setting. This improves the reliability of the POS loyalty functionality.
Original PR description
Step to reproduce - install `pos_loyalty` and have two companies - for this record: `loyalty.gift_card_product_50` set company_id = company1 - switch to company b and start pos Observation: - no products are loaded Cause: - `browse()` was used to load records `gift_card_product_50` and `ewallet_product_50` - when any of them is restricted on one company it fails to load whole model Fix: - Instead of directly loading them, we use `search()` to avoid `AccessError` so that rest of the products can be loaded. - Gift card is still not shown as expected opw-5449466 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244912
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 tracking. The change ensures that work entries accurately reflect the correct duration for each date, resolving a potential discrepancy in employee time records.
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 resolves a crash in the Delivery Slip report when printed in Spanish. The issue stemmed from the report using English labels for key fields, leading to errors. The fix now correctly targets technical fields for accurate reporting in 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 removes a problematic printing library, `python-escpos`, from the IoT drivers. While this library offered features like QR codes, it caused frequent printer issues and reliability problems. Switching to a simpler CUPS-based approach prioritizes stable printing performance, even if it means losing some advanced features.
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#249819
This update fixes an issue where deactivated tax rates were still being included in vendor payment calculations. The fix ensures that inactive tax rates are no longer considered when generating payments, improving the accuracy of financial reporting. This change was implemented by adding a filter to the tax retrieval process.
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 error that occurred when generating the XML FatturaPA for invoices in Italian companies. The issue stemmed from a mismatch in how data was being returned, leading to a technical error. This fix ensures invoices can be correctly downloaded in the required XML format.
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
This update fixes issues with downloading Activitywatch, specifically adding a link for the Linux (Ubuntu) build and correcting the existing Windows link. The update also improves how the system detects the user's operating system, ensuring a smoother download experience.
Original PR description
This PR adds the download link for the Ubuntu build of activitywatch, fixes the windows link, and fixes the platform detection.
This update resolves a technical issue causing emails sent by Odoo to be rejected by some email servers (like Yahoo). The fix prevents the system from folding subject headers, ensuring they comply with strict email standards and improving email delivery rates. This ensures our communications are reliably received by our customers.
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
This update adds a test to ensure the employee onboarding flow within the HR module functions correctly. It's a follow-up to a previous change designed to improve the stability and reliability of the employee onboarding process. This test helps ensure a smoother experience for new employees.
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
This update corrects a restriction preventing HR officers from creating new employees in Belgium. The fix utilizes 'sudo' to grant access to a specific field, allowing the correct creation process to proceed. This ensures all users can properly manage employee records.
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
This update resolves a technical issue related to the accurate calculation and reporting of cycle transportation declarations within the Belgian payroll module. The fix ensures compliance with Belgian tax regulations by correcting a data processing error, improving the reliability of payroll reports for businesses operating in Belgium.
Original PR description
Forward-Port-Of: odoo/enterprise#108069
This update resolves an issue where certain website snippets were unintentionally nested within other snippets, causing display inconsistencies. The changes prevent these specific snippets – related to popups, navigation tabs, and content tables – from being dropped into other snippets, ensuring a cleaner and more reliable website experience. This improves the overall presentation and stability of the website.
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 an issue where the payroll sheet calculation would fail if there were minor warnings during processing. The change allows the sheet to be generated even with warnings, ensuring payroll data is always available. This improves the reliability of payroll reporting.
Original PR description
Revert https://github.com/odoo/enterprise/pull/104137 Forward-Port-Of: odoo/enterprise#108340
This update resolves a problem where test data wasn't correctly applied during the development of the HR expense reporting feature. The team identified that changes made in a previous commit weren't being recognized by the tests. The fix ensures the tests run accurately using a default test company, maintaining the stability of the expense reporting system.
Original PR description
When adding the tests, the changes in d15faf0 were not taken into account. The tests wouldn't fail as the `hr_expense_stripe_demo` module would contain the necessary data runbot-241008 Forward-Port-Of: odoo/enterprise#108307
This update resolves an issue preventing proper testing of the Arabic VAT (AREDI) functionality. By using 'sudo()' when writing test data, the system now bypasses permission restrictions, ensuring reliable validation in testing environments. This improves the stability and accuracy of the AREDI module.
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 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
This update fixes an issue where message actions in the meeting chat were taking up excessive space, making message bubbles appear too small. The change adds necessary padding to the "..." button, ensuring a cleaner and more efficient display of message actions. This improves the overall user experience within the meeting chat.
Original PR description
Before this commit, message actions in meeting chat were taking too much space, reducing the size of message bubbles. This happens because the "..." button had no explicit padding and thus fall-backed to the default padding of a button, which is way too much. This commit fixes the issue by providing the proper padding to message actions in the inline presentation, which is necessarily with a tiny padding. Before / After <img width="297" height="565" alt="Screenshot 2026-02-20 at 18 38 05" src="https://github.com/user-attachments/assets/580bd0ff-ff3a-4830-bac4-6764e78863e2" /> <img width="296" height="562" alt="Screenshot 2026-02-20 at 18 37 41" src="https://github.com/user-attachments/assets/2f3eda5e-4016-402f-9450-157fe7be69bc" />
This update fixes an issue where the 'is_company' field wasn't accurately determined in Odoo's localization modules (l10n_br and l10n_ec). Now, Brazilian CNPJ and Ecuadorian RUC identification types correctly mark partners as companies, and foreign partners with VATs are also recognized as companies. This ensures accurate reporting and functionality for international business operations.
Original PR description
`is_company` was not correctly computed in some localization modules. This commit adds a compute method for: - l10n_br*: Company if identification type is CNPJ - l10n_ec*: Company if identification type is RUC For foreign partners (country ≠ BR/EC), a partner is considered a company if a VAT is provided. Follow-up of: https://github.com/odoo/odoo/pull/211043 Task-5947797
This update corrects a bug where the system incorrectly identified companies in Brazil and Ecuador. Now, the system accurately determines if a partner is a company based on their identification type (CNPJ or RUC in those countries) or if a VAT is provided for other countries. This ensures accurate reporting and accounting.
Original PR description
`is_company` was not correctly computed in some localization modules. This commit adds a compute method for: - l10n_br*: Company if identification type is CNPJ - l10n_ec*: Company if identification type is RUC For foreign partners (country ≠ BR/EC), a partner is considered a company if a VAT is provided. Follow-up of: https://github.com/odoo/enterprise/pull/86089 Task-5947797
This update resolves an issue where signature requests would fail with error messages due to a missing link to an employee offer. The fix ensures that signature requests are properly validated, preventing redirection errors and date validation issues. This improves the user experience for employees signing contracts.
Original PR description
Steps to reproduce: 1- On an employee page, create a new signature request for a document through the gear icon 2- Log in with the employee (ex. Marc Demo) and sign the contract 3- It will be signed but you will still get an <error 404 not found> page as it redirects to an offer that does not exist 4- Log in with the admin again to counter sign the document 5- You will get an error saying contract end date cannot be before contract start date Cause of the bug: We don't have an offer linked to the document we're signing. We can test this with the demo employee_contract.pdf or Employee Termination.pdf. The logic inside the sign() function will try to update the employee's version with fields from the offer which we don't have as it assumes this is a new offer. Fix done: Check if we have an offer linked to this sign request at first, if not return the default behavior that validates the signature. task-5423393
This update resolves an issue where a misleading warning appeared on payslips, even when employee wages were correctly calculated. The fix corrects a technical error in how the system checked net wages, ensuring the warning only appears when a payslip genuinely has a negative or zero net wage. This improves the accuracy and clarity of payroll reporting.
Original PR description
Steps to Reproduce: 1. Generate payslips for a batch of employees (e.g., Employee A and Employee B). 2. Ensure the last processed payslip (Employee B) has a negative net wage or is uncomputed (net…
Steps to Reproduce: 1. Generate payslips for a batch of employees (e.g., Employee A and Employee B). 2. Ensure the last processed payslip (Employee B) has a negative net wage or is uncomputed (net wage 0.0). 3. Ensure Employee A has a valid, positive net wage. 4. Open the payslip for Employee A. Issue: Employee A displays the warning "The net pay for this payslip is zero or negative," even though their net wage is positive. This occurred because the lambda filter used the `slip` variable from the outer loop scope instead of the iterator, causing the last record's net wage to determine the warning for the entire batch. Additionally, uncomputed payslips (which have no lines) default to a net wage of 0.0, which triggered the warning condition prematurely. Expected Behavior: The warning should only appear if the specific payslip being checked has a negative or zero net wage. Furthermore, the warning should be suppressed if the payslip lines have not yet been computed. Additionally, added a test to check the message is not displayed if we don't have net salary, and appears if the net is indeed negative. task-5484107
This update fixes a bug where users could accidentally create duplicate lines within Point of Sale orders. Previously, a refreshed page might send redundant requests, leading to multiple entries for the same item. Now, the system checks if a line already exists and updates it instead, ensuring data accuracy and a smoother user experience.
Original PR description
Before this commit, it could happen that a user send a request to the backend to create a pos.order.line that already exists because it didn't know it was already synced for some reason (the page was reloaded before getting the response and the frontend was then relying on indexedDB for example). It would then send a create command and we would have multiple lines with the same values. We have a constraint that usually works but for people where the bug happened before the constraint was created, the constraint would not be created and so the bug could still happen We now prevent that by changing the create command into an update command if the line to create already exists by comparing its uuid to the uuids of the lines related to the order. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249109
This update resolves an issue where the 'typing' indicator on chat channels remained visible indefinitely. The fix ensures that timeout expiration is correctly triggered when a user starts typing, regardless of timestamp duplication, improving the chat experience for users.
Original PR description
Typing expiration was indirectly tied to typing timestamp updates. Typing timestamps are second-precision, so two consecutive typing events can carry the same timestamp value. In that case, the timestamp field may not be considered updated on the client. The expiration timeout is then not re-armed even though typing is set to true. When that happens, the typing indicator can remain visible indefinitely unless an explicit "stop typing" event is received. This change makes timeout registration depend on typing state updates directly. Expiration is always scheduled when typing becomes active, regardless of timestamp equality. [task-4922630](https://www.odoo.com/odoo/project/1519/tasks/4922630) Forward-Port-Of: odoo/odoo#249917 Forward-Port-Of: odoo/odoo#249796
This update resolves an issue where a payment QR code remained visible on the customer display after an order was completed. The fix clears data related to the QR code when an order is finalized, ensuring a cleaner user experience. This improves the overall customer flow and prevents unnecessary visual clutter.
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 resolves an issue where the order of columns within the add snippet dialog was incorrect when using languages with different text directions (RTL/LTR). The fix ensures that the column order aligns with the backend language, improving usability for users with various language settings. This ensures a consistent and intuitive user experience.
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 ensures inactive taxes are accurately shown in fiscal position mappings, resolving a previous display issue. Previously, inactive taxes weren't consistently visible in key views. The change adds necessary context to the fiscal position action to ensure correct tax representation.
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 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. This improves the user experience when creating and managing sign templates.
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 fixes an issue where the names of Ecuadorian invoicing regimes didn't comply with government regulations. The changes ensure that all invoice data sent to the Ecuadorian tax authority (SRI) uses the correct, officially recognized regime names. This ensures compliance and accurate reporting.
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 resolves an issue that prevented users from clicking the Work Entries button when overtime records lacked a 'Stop' time. The fix corrects a comparison error between a datetime object and a boolean value, ensuring the button functionality is consistently available. This prevents a frustrating error for users managing overtime times.
Original PR description
Clicking the Work Entries smart button raises a traceback when an overtime record has no Stop (time_stop). Steps to reproduce the error: - Install ``hr_work_entry_attendance`` module with demo data -…
Clicking the Work Entries smart button raises a traceback when an overtime record has no Stop (time_stop). Steps to reproduce the error: - Install ``hr_work_entry_attendance`` module with demo data - Activate developer mode - Create an Employee A > Settings > Set Default Ruleset in Overtime Ruleset In Payroll Tab, Work Entry Source: ``Attendances`` and set Contract - Create an overtime attendance > Save > Open the Overtime Details > Unset the ``Stop(time_stop)`` > Save - Open Employee A > Click on Work Entries smart button Traceback: ```py TypeError: '<' not supported between instances of 'bool' and 'datetime.datetime' ``` https://github.com/odoo/enterprise/blob/56c3723a925f718ba39d11cde12933542ebcd7c1/hr_work_entry_attendance/models/hr_version.py#L49-L52 When ``stop(time_stop)`` is unset in the overtime, ``ot.time_stop`` is False, causing ``min()`` to compare a ``datetime`` with ``False``, which raises the above traceback. sentry-7169332615 Forward-Port-Of: odoo/enterprise#103764
This update resolves an error that occurred when employees had multiple leave types allocated. The fix ensures the holiday attest calculation accurately sums all available leave time, preventing a traceback during payroll processing. This improves the reliability of holiday pay calculations for employees with complex leave arrangements.
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 Forward-Port-Of: odoo/enterprise#107673
This update corrects a discrepancy in payslip calculations related to the private car allowance. The daily amount is now rounded to two decimal places, ensuring the displayed value precisely matches the 'Quantity × Amount' shown 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#108160 Forward-Port-Of: odoo/enterprise#106753
Features or functions removed from Odoo
This update eliminates redundant error messages related to IoT receipt printers. As we no longer track printer status, these warnings are no longer generated, streamlining the system and improving user experience. This change was made as part of a community contribution.
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#108109