Thursday, February 5, 2026
23 changes · saas-19.1
Resolved issues and error corrections
This update enhances the clarity of accounting entries related to company-account expense payments. By leveraging the 'payment_reference' field, the payment term line now displays user notes, providing better context and traceability for financial records. This aligns with standard invoice practices and improves overall accounting accuracy.
Original PR description
Currently, when creating a bill from an expense with payment_mode='company_account', the payment term line's name is set to an empty string because expenses are immediate payment expenses. However, users may enter notes in the payment_reference field. The account.move.line's `_compute_name` ([1](https://github.com/odoo/odoo/blob/3f4e45ecaca46a98c904536658728a1f1571bdbd/addons/account/models/account_move_line.py#L520)) method uses payment_reference to compute the name for payment term lines. By setting the name in needed_terms from payment_reference, the payment term line will display the user's notes, providing better context and traceability in the accounting entries. This change ensures consistency with the standard invoice behavior where payment_reference is used to populate the payment term line name. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244392 Forward-Port-Of: odoo/odoo#241353
This update fixes a technical error that prevented users from opening the cashbox when using the payment screen. The fix ensures the system correctly handles the 'Open Cashbox' click event, preventing a traceback error and ensuring the necessary context is available. This improves the reliability of the payment process.
Original PR description
In this commit: - Fixes a Traceback error when clicking "Open Cashbox" on the payment screen. - Ensures the correct context by using an arrow function. - Prevents `iface_cashdrawer` being undefined during the click event. Task:5890341
This update corrects a technical issue where API documentation wasn't accurately reflecting the types of list parameters in Odoo. The fix ensures that the documentation now correctly displays parameter types like 'list[int]' instead of just 'list', leading to more precise and reliable API documentation for developers.
Original PR description
In python 3.10; When the type of a method parameter is a container (eg: `list[T]`), `stringify_signature` was not getting the full type but only the origin of it (eg: `list` instead of `list[int]`). This commit fixes the issue by stringifiying the container types separately. runbot-237782 Forward-Port-Of: odoo/odoo#247149
Previously, removing or reordering images in the website gallery would lose all associated links. This fix ensures that image links are preserved when the gallery is updated, improving the user experience and preventing broken links. The change involved updating how image links are handled during gallery rebuilding.
Original PR description
Before this change, using the website editor with image galleries, removing or reordering an image caused all image links to be lost. This happened because the gallery was rebuilt using image nodes only, dropping anchor wrappers during the process. ### How to reproduce: * Open the website editor. * Add an Image Gallery block. * Add links to some of the images. * Remove or reorder an image. * All image links are lost. ### Solution: Pass image holders instead of raw images to setImages and handle the different gallery modes. opw-5422081 Forward-Port-Of: odoo/odoo#244417
This update fixes a minor issue where some onboarding tours weren't properly waiting for the portal chatter to load, leading to potential delays for users. The fix ensures tours wait for the chatter to be ready before proceeding, improving the overall user experience and preventing a warning related to DOM updates during selection. A minor typo in a file name was also corrected.
Original PR description
### Before commit Some tours did not wait for the portal chatter to load when needed: - `portal_chatter_bundle`: the `run` function creates a promise but the tour finishes before it resolves. - `fullscreen_slide_text_highlights`: `PortalChatterService` adds an element in the DOM while the selection is updated in the `selectText` tour step. This caused the following warning to show: ``` should not have any "characterData", "remove" or "add" mutations in current step when you update the selection ``` ### Fix Properly wait for `portalChatterReady` to resolve before proceeding with the rest of the tour steps. (Also fixed the typo in the filename `slide_portal_chatter_bundle.js`) runbot-229803 Forward-Port-Of: odoo/odoo#247203
This update resolves a technical issue where the user ID (UID) was incorrectly set during the MFA process. A recent code change inadvertently caused this, which was preventing proper MFA functionality. This fix ensures the UID remains correctly set to 'None' during MFA, improving system stability and security.
Original PR description
Before this fix the uid was set in the environment even when the MFA was not yet complete. The uid is set in finalize function and was accidentally set before due to a refactor of DLE. This was indeed a bug since the code expects the uid to be set to None. Task-5910537 Forward-Port-Of: odoo/odoo#247230
This update resolves an issue where resizing an image within a link would unexpectedly make it fill the entire link width. The fix ensures that image resizing within links maintains the intended proportions, providing a more consistent and user-friendly experience. This improves the visual quality of linked images.
Original PR description
Problem: Resizing an image inside a link causes it to snap to 100% width on mouseup. Cause: The percentage calculation uses the parent element's width as reference. When the parent is inline (like `<a>`) or has fit-content width, its width equals the image width, resulting in 100% every time. Solution: Find the first ancestor with content width larger than the image and use it as reference for the percentage calculation. Steps to reproduce: - Add an image inside a link - Resize the image - Observe the image snaps to 100% width on release opw-xxxx --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247229
This update resolves minor visual inconsistencies in the new image gallery template. Specifically, it corrects issues with missing styling and undefined class names, ensuring a more polished and reliable display of images for users. This improves the overall user experience.
Original PR description
This commit fixes a few minor issues in the new carousel items template introduced in [1]: items having an `"undefined"` class, and a missing margin style in the main snippet template. [1]: https://github.com/odoo/odoo/commit/9042b1cae7b630b20e0670788b7a4ed9e4c97609 linked-task-3414281 Forward-Port-Of: odoo/odoo#245357 Forward-Port-Of: odoo/odoo#241785
This update corrects a technical issue where inconsistent environments were causing errors in automated mail sending processes within Odoo. By standardizing the environment context, the system now reliably avoids these concurrent update errors, ensuring stable operation.
Original PR description
### [FIX] base: ensure an uniform environment between action variables The aim of this commit is to make the environment and context uniform across the variables that can be accessed in an action. Context: The mail override of `<ir.actions.server>._get_eval_context` that modifies the `env` wasn't reflected on the other variables which lead to a difference of context. Before this commit: This difference resulted in a concurrent update error caused by a direct mail send in method like `_cron_try_auto_reconcile_statement_lines`. After this commit: The environment and its context are uniform as expected and cron don't trigger a mail send directly, removing the concurrent error issue. task-id: None The issue was brought in the internal channel, temporarily fixed by adding the context in the server action and seen again in odoo.com logs through another cron. Forward-Port-Of: odoo/odoo#247255
This update fixes an issue where recurring prices on ecommerce product pages were displayed with incorrect grammar, specifically using singular forms for billing periods longer than one. The change ensures all recurring price labels are pluralized, providing a more professional and user-friendly experience for customers.
Original PR description
Issue: - On ecommerce product pages, recurring prices displayed incorrect grammar. - Billing periods greater than one were shown in singular form (e.g. 'Every 6 month' instead of 'Every 6 months'). Fix: - Updated recurring price display logic to use plural period labels when the billing period value is greater than one. Impact: - Recurring prices now display correct and user-friendly grammar. taskid-5529937 Forward-Port-Of: odoo/enterprise#105127
This update resolves an issue where the printer selection wizard could generate errors if it encountered printers that were no longer active in the system. The change filters out these inactive printers, ensuring the wizard functions smoothly and avoids potential disruptions. This improves the user experience and data integrity.
Original PR description
Printers saved by the selection wizard in local storage can correspond to records that no longer exist in the database (removed in the meantime). To avoid a traceback when creating the wizard with non- existing printers, we filter out the ones that don't correspond to any device. Forward-Port-Of: odoo/enterprise#106268
This update resolves an issue where malformed PDFs caused errors during the signature process. The change allows Odoo to attempt a less strict PDF parsing method, ensuring that more PDF documents can be successfully processed and used for signatures. This improves the reliability of the signature workflow.
Original PR description
Before this commit, opening some malformed PDF failed during flattening because PyPDF2 strict parsing and form-field reads raised errors. After this commit, we try first parsing the PDF in the usual way and if we fail, we try again with strict=False. See https://pypdf.readthedocs.io/en/stable/user/robustness.html. task-5902859 Forward-Port-Of: odoo/enterprise#106276
This update corrects a bug that was incorrectly flagging miscellaneous entries with both expense and revenue accounts as invalid. Previously, the system would generate an error when using different deferred entry methods for expenses and revenues. Now, the validation only applies to entries with actual deferred dates configured, improving usability for common accounting scenarios.
Original PR description
The `_get_deferred_entries_method` checks for expense/income account conflicts using all line accounts, not just lines with deferred dates. This causes a false positive error when posting misc…
The `_get_deferred_entries_method` checks for expense/income account conflicts using all line accounts, not just lines with deferred dates. This causes a false positive error when posting misc entries with both expense and revenue accounts but no deferred dates configured. https://github.com/odoo/enterprise/blob/3e6d2f3ca7e2d4e940f2c2022f816202c72cbd1b/account_accountant/models/account_move.py#L150-L151 Steps To Reproduce: 1. Go to Settings → Accounting and set different "Generate Entries" methods for deferred expenses "On bill validation" and deferred revenues "Manually & Grouped". 2. Go to Accounting Dashboard and create a new Miscellaneous Operation. 3. Create 2 journal items: one with an expense account and one with a revenue account (neither configured for deferred entries). 4. Try to post the entry. 5. Error appears: "Having different deferred entries generation methods for expenses and revenues is not supported..." The validation should only apply when lines actually have deferred dates set, not for all misc entries with mixed account types. Commit that caused the issue: https://github.com/odoo/enterprise/commit/3e6d2f3ca7e2d4e940f2c2022f816202c72cbd1b Ticket [link](https://www.odoo.com/odoo/project.task/5486114) opw-5486114 Forward-Port-Of: odoo/enterprise#104476
This update ensures that product prices within Odoo Enterprise are stored with a minimum level of precision. This change addresses a technical issue identified in previous development and improves data consistency. It primarily impacts the accuracy of product pricing calculations.
Original PR description
Fix tests, related to https://github.com/odoo/odoo/pull/243987 task-4895014 Forward-Port-Of: odoo/enterprise#106382 Forward-Port-Of: odoo/enterprise#104728
This update simplifies the one-time payment form accessed through the employee record. The version field, previously required, has been removed as it's automatically determined by the system. This change ensures a cleaner user experience and avoids potential errors related to incorrect employee or version selection.
Original PR description
… payment form The one time payment view is accessed only via the smart button on the employee form for a specific version. This view displays only that employee's one time payments for the selected version. Since the version is provided by the context and creating a payment for a different employee or version would not make sense, the version field is made invisible. Task: 5384437 Forward-Port-Of: odoo/enterprise#103245
This update resolves a technical problem where sales commission IDs were exceeding JavaScript limits, causing errors. The fix increases the range of the plan ID, allowing for a significantly larger number of sales plans (from 900 to 90,000) while maintaining security and minimizing the risk of duplicate records.
Original PR description
Issue: 10^13 was too big of an exponent as such the id generated were bigger than JS limit `Number.MAX_SAFE_INTEGER`, this resulted in the id being rounded to the nearest reprentable integer. Which resulted in a traceback as we were fetching records that didn't exist. This fix allow a bigger margin for the plan_id while keeping the collusion risk equal, as we have the following: - user_id margin is 10^5 - date is in YYMMDD format, so it occupies at most 6 integer - plan_id can thus occupy the space after which is 5 + 6 so 10^11 Only issue possible left with this id generation would be to have user that are 1000 id apart, with same date and same plan. Or that we have too much plan that we exceed the JS limit. Number of plan that can be handled with this change goes from ~900 -> ~90000 which seems reasonable. Forward-Port-Of: odoo/enterprise#106513
This update corrects a technical issue related to the HR payroll tour in the Swiss localization. The tour was incorrectly displaying a Work Entries button, which isn't relevant for Swiss companies. This fix ensures the tour functions correctly for Swiss businesses, streamlining the payroll process.
Original PR description
The Work Entries button on the form view of the hr_payslips is defined differently in the Swiss localization. We need to override the tour to make it work for swiss companies. Runbot Error: 234647 Forward-Port-Of: odoo/enterprise#106147
This update fixes a potential issue where applicants could incorrectly reopen and re-sign expired job offers. The system now prevents access to fully signed offers, ensuring data integrity and a smoother applicant experience. A database constraint has also been added to prevent invalid offer validity dates.
Original PR description
This commit improves the offer validation logic to avoid invalid or unintended signature attempts. Fixes included: - Block access to offers that are already fully signed, preventing applicants from reopening the link and unintentionally reverting the offer to a partially signed state. - Add an SQL constraint on the `validity` field to disallow negative values, ensuring that expired/invalid offers cannot be accessed due to incorrect validity data. These changes ensure that expired or fully processed offers no longer expose active signature links and that offer validity is consistently enforced at the database level. task-5405456 Forward-Port-Of: odoo/enterprise#104354 Forward-Port-Of: odoo/enterprise#101834
This update fixes an issue where appraisal templates couldn't select departments without a linked company. The fix ensures all departments, including those without a company association, are now available for selection within the template configuration. This improves usability and prevents limitations in defining appraisal processes.
Original PR description
### Issue:
On the appraisal template form view, the dropdown of "Departments" does not show departments with no company.
### Steps to reproduce:
- In the Employee app create a new Department with no company
- Go in Appraisals > Configuration > Appraisal Templates
- Click on a template, remove it's company if it has one
- Try to change the Department of the template
- The new department does show
### Cause:
The field `department_ids` on `hr.appraisal.template` have this domain: `(company_id and [('company_id', 'in', [company_id, False])] or [('company_id', 'in', allowed_company_ids)])` It excludes departments with no company when the template have no company because `allowed_company_ids` doesn't contain `False`.
### Solution:
Add `False` in `allowed_company_ids`.
opw-5354581
Forward-Port-Of: odoo/enterprise#103531This update fixes an issue where the employee's filling status wasn't updating correctly when the associated address state was changed. The fix adjusts the system to dynamically reflect the correct filling status based on the employee's working address location, ensuring accurate payroll calculations for users in different states.
Original PR description
to reproduce: ============= - create employee and set working address with state in CA - set filling status to match the state - in the address record change the state to AL (don't change the record in employee) - go back to employee form view, filling status is still the same problem: ======== currently we are relying on a constraint to check if the filling status is valid for the state in the working address. But `api.constrains` doesn't support dotted paths, so modifying `address_id.state_id` doesn't trigger it. solution: ========= make the filling status computated field depending on `address_id.state_id` opw-5878740 Forward-Port-Of: odoo/enterprise#106000
This update resolves an issue where toggling the Studio feature in Odoo Enterprise could disrupt the layout of form stat buttons. The fix ensures the stat button layout remains consistent, regardless of whether Studio is active, improving the user experience and preventing potential formatting problems.
Original PR description
**Before this commit:** Toggling Studio could break the layout of form stat buttons. **After this commit:** The stat button layout remains intact when Studio is toggled. task-5480309 Forward-Port-Of: odoo/enterprise#106452
This update resolves an issue causing duplicate Worldline receipts to appear in POS transactions. The fix ensures receipts are only added when a Worldline transaction is fully completed, improving the accuracy and reliability of sales records. This prevents potential discrepancies and ensures data integrity.
Original PR description
This PR fixes the issue where Worldline receipts were sometimes added twice to the pos receipt by only modifying the receipt if the transaction has been finished (currently we modify the receipt no matter the message type (cancellation/payment failed etc.)) ticket-5342655 Forward-Port-Of: odoo/enterprise#106554
This update ensures that sign templates are correctly named in all languages, reflecting the actual document being signed. Previously, templates created in non-English languages defaulted to 'New Template' due to a comparison issue. This fix guarantees accurate naming across all supported languages, improving the user experience and data consistency.
Original PR description
## Steps to reproduce: 1. Upload a new PDF document to be signed. 2. Select it in the Documents app to sign it. 3. Check the name of the sign template created. ## Issue: When creating signature templates in languages other than English, the template name would stay as "New Template" instead of updating to the actual document name. This happened because the code was comparing the template name against a translated version of "New Template", but the template was initially created with the English default value. Since "New Template" ≠ "Nueva Plantilla" (Spanish), the comparison failed and the name never got updated. The fix ensures we always compare against the original English default value, so the template name gets properly updated to match the document name regardless of the user's language. Related commit: 4254542 opw-4980747 Forward-Port-Of: odoo/enterprise#104846 Forward-Port-Of: odoo/enterprise#92682