Daily updates from Odoo
Monday, June 15, 2026
233 changes
3 changes
Enhancements to existing features
This update now automatically logs the reasons why orders are skipped during synchronization with Lazada. Previously, users had to manually investigate order details to understand the cause. This enhanced logging provides clearer insights into synchronization issues, streamlining troubleshooting and improving order processing reliability.
Original PR description
Before this commit, the only way to know why an order was not synchronized was to inspect the order details and infer the reason from the code. This commit now logs those reasons. Forward-Port-Of: odoo/enterprise#120212
Resolved issues and error corrections
This update resolves an issue where the version timeline widget was causing unnecessary page reloads when versions were updated. The fix replaces a delayed refresh with a more efficient method of triggering a data refresh, resulting in smoother and faster timeline updates. This improves the user experience.
Original PR description
A useEffect was added to clear the cache of the versions in case of generation or removal of versions. This is not the best as it waits for everything to be rendered and applied to the DOM to trigger a reload. The alternative is to add a context to the widget and to the orm.searchRead, to trigger a cache miss on version change. task-6289891 Forward-Port-Of: odoo/odoo#269089
This update resolves an issue where the URL used for OAuth authentication with the Romanian tax authority (ANAF) was incorrectly generated. The previous method relied on the user's current session, leading to a mismatch with the registered URL. This change ensures the correct URL is used, allowing for proper authentication and tax reporting.
Original PR description
The `_compute_l10n_ro_edi_callback_url` method was using `request.httprequest.url_root` to build the OAuth callback URL. The URL is derived from the current HTTP request, meaning it reflects however the user accessed the session at that moment (e.g. internal IP, localhost, non-standard port). This produces a callback URL that does not match what was registered with ANAF, breaking the OAuth flow. 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#268974 Forward-Port-Of: odoo/odoo#265000
5 changes
Resolved issues and error corrections
This update fixes an issue where changes made to leave details within the popover form weren't being saved correctly. The fix introduces a delay to handle rapid changes and ensures that modifications are saved, improving the user experience when managing time off requests. It also maintains access to key actions like 'Refuse' and 'Delete'.
Original PR description
Steps:- - Navigate Payroll > Time Offs. - Create a leave of any type (STO, PTO etc...) - Click on the pill after creating leave. - Try to change values on popover. - Changed values are not saved!! Cause:- There is no save action trigger on popover form. Fix:- - Hooked `debounceAutoSave` method on every field value changes. - `debounceAutoSave` will save record with 500ms debounce to batch rapid changes. - Set popover form to readonly mode for validated leaves (validate/validate1 states) - Remove readonly condition from action buttons footer to keep Refuse/Delete accessible task-[6117310](https://www.odoo.com/odoo/project/1251/tasks/6117310)
This update resolves an issue where the version timeline widget was causing unnecessary page reloads when versions were updated. The fix replaces a delayed refresh with a more efficient method of triggering a data update, resulting in smoother performance and faster loading times for version history.
Original PR description
A useEffect was added to clear the cache of the versions in case of generation or removal of versions. This is not the best as it waits for everything to be rendered and applied to the DOM to trigger a reload. The alternative is to add a context to the widget and to the orm.searchRead, to trigger a cache miss on version change. task-6289891 Forward-Port-Of: odoo/odoo#269089
This update fixes a visual issue where debit notes generated as PDFs incorrectly displayed 'INVOICE DINV...' instead of 'DEBIT NOTE DINV...'. This change ensures that debit notes are clearly distinguishable from invoices in printed and emailed documents. The fix was driven by a customer request to improve clarity and accuracy.
Original PR description
### Steps to reproduce the issue: 1. Download Invoice and Debit Notes 2. Go to an invoice (or create a new one) 3. Create a debit note for that invoice and print it or send it 4. In the PDF the title is 'INVOICE DINV....' instead of 'DEBIT NOTE DINV...' ### Reason to introduce the fix: Differentiate debit notes from invoices. opw-6252239 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#268207
This update resolves an issue where the URL used for OAuth authentication with the Romanian tax authority (ANAF) was incorrectly generated. The previous method relied on the user's current session, leading to mismatched URLs and failing authentication. This change ensures the correct, standard URL is used, allowing for proper tax reporting functionality.
Original PR description
The `_compute_l10n_ro_edi_callback_url` method was using `request.httprequest.url_root` to build the OAuth callback URL. The URL is derived from the current HTTP request, meaning it reflects however the user accessed the session at that moment (e.g. internal IP, localhost, non-standard port). This produces a callback URL that does not match what was registered with ANAF, breaking the OAuth flow. 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#268974 Forward-Port-Of: odoo/odoo#265000
This update resolves an issue where the VoIP softphone would generate errors when receiving calls from numbers not linked to a contact. The fix ensures that task creation from contactless calls works as expected, and the 'Tasks' button is hidden when no contact is associated with the call, preventing errors and improving usability.
Original PR description
**Problem:** Two linked errors occur in the Phone (VoIP) softphone when a call is made to or received from a number that is not linked to any contact. **Steps to reproduce:** 1. Receive or make a…
**Problem:** Two linked errors occur in the Phone (VoIP) softphone when a call is made to or received from a number that is not linked to any contact. **Steps to reproduce:** 1. Receive or make a call from the softphone using a phone number that is not linked to any existing contact. 2. Open the call's actions and click "Create" > "Task". -> A client error appears and the task is not created. 3. On a voip.call form whose Contact has been removed, click the "Tasks" smart button. -> A server error is raised. **Current behavior:** Step 2 raises "Cannot read properties of undefined (reading 'id')" and step 3 raises "ValueError: not enough values to unpack (expected 1, got 0)". **Expected behavior:** Creating a task from a contactless call should open the task form without a default contact, and the Tasks smart button should not be reachable when the call has no contact. **Cause of the issue:** Both code paths assume a call always has a linked partner. In `action_list_patch.js`, `getCreateTaskAction` only checks `shouldShowTaskButton` in its predicate but reads `this.contact.id` in its `onClick`; for a contactless call `this.contact` is undefined. In `voip_call.py`, `action_view_tasks` delegates to `self.partner_id.action_view_tasks()`, whose `ensure_one()` fails on the empty partner recordset. Unlike the softphone "view tasks" action, which is gated by `this.contact?.task_count`, the form stat button had no visibility guard. **Fix:** The create-task action now mirrors the existing contact and lead actions, which already build their context conditionally on `this.contact`, so a contactless call simply opens the task form with no default partner. The Tasks stat button is hidden when there are no tasks, matching the softphone predicate and ensuring the partner-less code path is never reached. opw-6246641
8 changes
Resolved issues and error corrections
This update resolves a bug that occurred when grouping financial reports by account code. The issue was caused by comparing numerical and string values, leading to a crash. The fix ensures account codes are treated as numbers during sorting, improving the stability of financial reporting.
Original PR description
If you're grouping by account_code on a line using an account_code
engine, and there's a None value, it will crash.
To get that, you can (with demo data):
- install l10n_be
- set "BE Company COA" as the main, keeping "My Company (San Francisco)"
activated
- go to the profit and loss "Profit and Loss (Abbr) (BE)", set the date
as the current year
- set "Consolidation" filter
- Unfold "60/61 - Goods for Resale,..."
```
Traceback (most recent call last):
...
File "... in _compute_formula_batch_with_engine_account_codes
results_list.sort(key=lambda x: math.inf if x[0] is None else x[0])
TypeError: '<' not supported between instances of 'float' and 'str'
```
Because in case of `None`, we compare with `math.inf` but the account
codes are string.
no-taskThis update addresses a missing rule in the calculation of employer costs within the Odoo Enterprise system. Following a review, a crucial rule was added to ensure accurate employer cost reporting, aligning with previous improvements. This ensures compliance and accurate financial reporting.
Original PR description
In this previous PR https://github.com/odoo/enterprise/pull/106839 the computation of the employer cost was fixed and many rules were flagged as needed in that computation. After a report, we found one of the rules was missing so we add it in this PR. Task: 6088412 Forward-Port-Of: odoo/enterprise#112681
This update ensures website configuration consistently generates necessary snippet templates, particularly when using eCommerce themes. Previously, a configuration error caused a retry, leading to duplicate menu items. Now, templates are created proactively, resolving the issue and improving website build stability.
Original PR description
Steps to reproduce: - Start from a database where the eCommerce app is not installed. - Open the website configurator. - In the first step, choose "I want an eCommerce". - In the Pages and Features…
Steps to reproduce: - Start from a database where the eCommerce app is not installed. - Open the website configurator. - In the first step, choose "I want an eCommerce". - In the Pages and Features step, select all Pages. - Select a theme that adds an eCommerce category snippet, for example "Treehouse". - Build the website. => During the first `configurator_apply`, `website_sale` is installed after the theme and the configured menu items are already created. => The homepage rendering then needs a `website_sale` configurator snippet template requested by the theme, but it was not generated during that first call. => The client retries `configurator_apply`. It now succeeds because `website_sale` is fully installed, but page and menu creation runs again and duplicates the menu items. Before this commit, primary snippet template generation only read the manifest of the module being generated. When `website_sale` was installed from the first `configurator_apply`, it did not see addon snippets declared by the already installed theme. The first call could therefore fail while rendering the homepage after pages and menus were created. After this commit, generation also reads installed theme addon snippets that target the module being generated. The `website_sale` configurator templates requested by the selected theme are created before the first homepage rendering, so `configurator_apply` does not retry after creating menu items. task-5973739 Forward-Port-Of: odoo/odoo#261022
This update improves the overtime regeneration process in the HR module. Previously, regenerating overtime reset all overtime records, regardless of the selected ruleset. Now, it only affects the chosen ruleset and prompts users for confirmation before resetting any manual edits, ensuring data accuracy and preventing unintended changes.
Original PR description
When you click on "regenerate overtime", currently, it reset all overtimes of all overtime ruleset, it should only act on the selected one. Second, it should display a confirmation message: "This will reset all manual edit on overtime period linked to those rules. Do you confirm ?" Task-6095714
This update resolves an issue where the version timeline widget was causing performance slowdowns by unnecessarily reloading the entire page. The fix replaces a delayed refresh with a more efficient method of triggering a data update, resulting in faster and smoother version tracking. This improves the user experience when managing different versions of data.
Original PR description
A useEffect was added to clear the cache of the versions in case of generation or removal of versions. This is not the best as it waits for everything to be rendered and applied to the DOM to trigger a reload. The alternative is to add a context to the widget and to the orm.searchRead, to trigger a cache miss on version change. task-6289891 Forward-Port-Of: odoo/odoo#269089
This update fixes a visual issue where debit notes generated in Odoo were incorrectly labeled as 'INVOICE DINV...' in downloaded PDFs. Now, the PDF title clearly identifies the document as a 'DEBIT NOTE DINV...', ensuring invoices and debit notes are easily distinguishable. This improves clarity and accuracy for users.
Original PR description
### Steps to reproduce the issue: 1. Download Invoice and Debit Notes 2. Go to an invoice (or create a new one) 3. Create a debit note for that invoice and print it or send it 4. In the PDF the title is 'INVOICE DINV....' instead of 'DEBIT NOTE DINV...' ### Reason to introduce the fix: Differentiate debit notes from invoices. opw-6252239 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#268207
This update fixes an issue where the quantity on hand for products across multiple companies was incorrectly calculated. The fix ensures accurate FIFO valuation by including all company movements in the calculation, particularly for lot-valuated products, leading to more reliable inventory reporting.
Original PR description
The quantity on hand for a main company with branches is calculated to be the the sum of all its child companies + its own quantities. `_run_fifo_get_stack()` doesn't include the child companies in…
The quantity on hand for a main company with branches is calculated to be the the sum of all its child companies + its own quantities. `_run_fifo_get_stack()` doesn't include the child companies in the `moves_domain`, so it is unable to create a FIFO stack for moves from a child. This leaves extra quantity unaccounted for, which defaults to the standard_price. **Video of the bug:** https://drive.google.com/file/d/11PIfNAIb_Yyo4A-3R0CRF0NV6_HE6EwF/view **Issue:** When multiple companies are selected, the displayed quantity on hand for a product is calculated as the sum of all selected companies. However, the moves domain only looks at the main selected company instead of all selected companies, leading to an incorrectly calculated standard price when using FIFO. This is more apparent on lot-valuated products because the lot standard price is recalculated every time the field is accessed. **Reproduction steps:** - Have a main company - Create a branch company - Create a product, configure it as FIFO on both the main company and branch company - Let the product be tracked by lots and set to `Valuation by Lot` (for demonstrative purposes) - On the main company, set the product cost to $15 (for demonstrative purposes) - Go to only the branch company, make a purchase for one unit of the FIFO product at $100 (make a warehouse for delivery) , validate the receipt - Go to the lot -> When logged in to only the branch company, quantity is 1 and cost is $100 (correct). When logged in to both the main and branch company and viewing from the main company, quantity is 1 and cost is $15 (incorrect) **Fix:** Allow `_run_fifo_get_stack()` to see the moves from all companies in the environment instead of just the main company Related ticket: opw-6064126 Forward-Port-Of: odoo/odoo#258199
This update resolves an issue where the URL used for authentication with the Romanian tax authority (ANAF) was incorrectly generated. The previous method relied on the user's current session, leading to mismatches and preventing successful authentication. This change ensures the correct URL is used, allowing seamless integration with ANAF.
Original PR description
The `_compute_l10n_ro_edi_callback_url` method was using `request.httprequest.url_root` to build the OAuth callback URL. The URL is derived from the current HTTP request, meaning it reflects however the user accessed the session at that moment (e.g. internal IP, localhost, non-standard port). This produces a callback URL that does not match what was registered with ANAF, breaking the OAuth flow. 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#268974 Forward-Port-Of: odoo/odoo#265000
1 change
Resolved issues and error corrections
This update fixes an issue where the quantity invoiced on a sale order wasn't correctly updated after a refund was processed from the PoS. The fix ensures that refund amounts are accurately reflected in the sale order's invoice quantity, resolving a previous inconsistency between PoS and backend refund processes. This improves the accuracy of sales reporting.
Original PR description
When making a refund of a PoS order that was created from a sale order, the sale order qty_invoice was not updated correctly. Steps to reproduce: ------------------- * Create a sale order with any product and confirm it * Open a PoS and settle the order * At this point the qty_invoiced should be 1 on the sale order line * Refund the PoS order from the PoS > Observation: The qty_invoiced is still one. Why the fix: ------------ We now take refund lines into account when computing the qty_invoiced. Note: ------------ There was an inconsistency between a refund made from the PoS and a refund made from the backend. The former is not linking the sale order line to the refund line, while the latter does. This was causing issue when refunding from the backend as it would count the refund twice. To fix this we now remove the link to the sale order line when refunding from the backend. opw-4991405 Forward-Port-Of: odoo/odoo#269347 Forward-Port-Of: odoo/odoo#259653
10 changes
New functionality added to Odoo
This update allows clients to track and pay monthly homeworking fees to employees as a benefit. New salary rules and associated benefits were added within employee settings, providing a structured way to manage these expenses. This improves payroll accuracy and reporting related to remote work arrangements.
Original PR description
In order to allow clients to allocate daily homeworking fees to be paid as a monthly benefit to the employees, new salary rule and its benefit were added to the employee settings. Task: 6037614
This update adds functionality to generate the Form 2316, a crucial annual tax certificate required for compliance with Philippine regulations (CAS). The changes accommodate the Philippines' unique naming convention (first, middle, and last names) and ensure accurate reporting of employee compensation and tax withholdings, aligning with legal requirements.
Original PR description
Implement support to generate the Form 2316, the annual certificate of Compensation Payment/Tax Withheld that is individual to each employee. This is a requirement for a software to be compliant with CAS task-6215945
Enhancements to existing features
This update enhances the way sick and work accident leaves are processed for short-term contracts. The changes now consider contract duration and seniority levels to accurately determine the eligibility and calculation of these leaves, ensuring compliance and improved accuracy in payroll processing.
Original PR description
Refine sick/work accident leaves split based on contract duration and seniority. task-5480458
This update improves the accuracy of payroll calculations in Belgium by adding validation rules for reclassification schemes. Specifically, it prevents incorrect scheme selections based on notice period length and employee details, ensuring compliance and reducing potential errors. A helpful message has also been added to the outplacement field.
Original PR description
- Add a help message to the outplacement field explaining its purpose and services. - Prevent selecting the General scheme if the notice period is less than 30 weeks. - Prevent selecting the Specific scheme based on notice period length, employee age, company sector, and seniority. Task Id: 6267824
This update streamlines the process of sending payslips via email, making it much easier for HR to send PDFs to employees. The new 'Send by Email' button allows for bulk sending of validated payslips with a single click, eliminating the previous complex manual process. Additionally, the UI has been improved to prevent overlapping elements and remove unnecessary options.
Original PR description
[IMP] hr_payroll: ease UX for payslip sending via email
Send the emails for at least validated payslips is quite hard and takes time, it was in the cog and all employees must be selected. Instead I used a new Send by email button that sends the email to all employees in one click to the button
Firstly, if there are payslips without PDF's the Print Payslips button appears, if there is not, then send by email button appears.
"Mark as Paid" is made invisible
I also played with the max-width of the top-bar of the payrun (which includes statusbar, title etc) to prevent any kind of element overlaps.
task - 5979720This update corrects an issue where automatically adjusted quantities in rental sales were leading to incorrect invoicing. It ensures ordered and delivered quantities remain independent, aligning with the existing invoicing policy and preventing over-invoicing. The change also standardizes product display names across reports and portals for better customer clarity.
Original PR description
** For `sale_renting` ** With the introduction of product-less Sale Order Lines in the community version, we noticed that for manually delivered lines, the ordered quantity gets automatically…
** For `sale_renting` ** With the introduction of product-less Sale Order Lines in the community version, we noticed that for manually delivered lines, the ordered quantity gets automatically adjusted to match the delivered quantity. This behavior is unnecessary. The invoicing policy already determines which quantity should be invoiced. By forcing the ordered quantity to match the delivered quantity (especially when delivered > ordered), we end up consistently invoicing the higher value, which is not always correct. In practice, ordered and delivered quantities commonly differ, so they should remain independent. ** For `sale_commission` ** For commission and achievement reports, productless lines are aggregated under plans having no product restrictions ** For `sale_account_accountant` ** For accural entries non downpayment lines having no display_type are shown instead of restricting only lines having product. Removed product_invoice_policy field and used the `sale.order.line.invoice_policy` search compute field. Technical changes * From now on any SOL should contain name field value as `product.display_name+ "\n" + description` for consistancy with normal SOLs since we show only `line.name` in reports and portal so in case it should contain product name otherwise it could be confusing for customers to see just description. * Updated renting-specific extensions of `SaleOrderLineProductField` to also patch `SaleLabelTextField`, ensuring consistent behavior when product search is triggered directly from the description field. * Preserved existing renting configurator and combo behaviors while supporting the new searchable description field flow. * Removed the automatic synchronization between ordered and delivered quantities for manually delivered rental lines. * Adapt some tests to company specific Automatic Invoice setting field. task-6109825 See Also: - https://github.com/odoo/odoo/pull/259842 - https://github.com/odoo/upgrade/pull/9981
Resolved issues and error corrections
This update fixes a potential issue where employee payslips in the Belgian payroll module (l10n_be_hr_payroll) could display a negative net salary due to high fiscal voluntarism deductions. The change caps these deductions to prevent net salaries from going below zero, ensuring accurate payroll calculations.
Original PR description
In cases where an employee has a low taxable amount (e.g. due to many unpaid work entries) and a high fiscal voluntarism deduction, the resulting payslip could compute a negative net salary. This commit caps the fiscal voluntarism deduction to the remaining taxable income after withholding taxes, ensuring the net salary never drops below zero due to this rule because of the Fiscal Voluntarism Task Id: 6283617
This update removes duplicate time off types from the l10n_be_hr_payroll module. We've streamlined the system to only retain the essential Postponed Paid Time Off N-1 and N-2 types, simplifying payroll processing and reducing potential errors. This change ensures consistency and accuracy in time off calculations.
Original PR description
We only keep the Postponed Paid Time Off N-1 and N-2 types. task-6292642
This update adjusts the payrun warning button on the payroll dashboard to accurately reflect the status of each payrun. When a payrun is fully paid, the button now displays 'Review'. However, if any payslips remain in 'Draft' status, the button continues to show 'Continue' to guide users appropriately.
Original PR description
- Current behavior: the payrun warning button in the payroll dashboard shows "review" if payrun is in stage "03_paid", otherwise "Continue". - New behavior: if a pay run is marked as Paid, the button should display "Review" instead of "Continue"; however, if any payslip is still in the Draft stage, then the button should continue to display "Continue". Task: 6216477
This update ensures the correct appraisal template is automatically assigned to employees based on their department. Previously, the system ignored department-specific templates. Now, it selects the lowest numbered template matching the employee's department or a template with no department assigned, ensuring accurate appraisal workflows.
Original PR description
**Before this commit:** - We were never setting the appraisal template based on the employee's department. Instead, we were ignoring all templates that had a department assigned. And were choosing the first template. **After this commit:** - We will select the first lowest sequence template that satisfies either of the following conditions: 1. The template's department matches the employee's department. 2. The template has no department assigned. task: [6255087](https://www.odoo.com/odoo/project/1251/tasks/6255087)
4 changes
Resolved issues and error corrections
This update fixes a security vulnerability where users without approval permissions could incorrectly interact with approval requests, leading to errors. The change restricts access to 'Accept' and 'Refuse' options within approval activities to only the designated approver, enhancing security and preventing unintended actions.
Original PR description
Currently when a user submits an approval request, an activity is created for the approver who can validate or refuse the request directly from the activity, however these options are also visible to other users who will trigger an error if interacting with the options. This commit removes these options for users who are not the approver. **Steps to reproduce:** - Log in as admin - Go to approvals - Select dropdown menu of General Approval and Edit - Change documents to optionnal - Make sure admin is in the approvers list - Log in as demo - Go to approvals -> General Approval -> New Request - Submit the request - You'll see an activity be created for admin, with Accept and Refuse options - If you select any of these options you will get an access error opw-5423528
This update resolves an issue where expense descriptions weren't automatically translated when using different database languages (like French). The fix ensures that OCR-extracted descriptions are correctly applied, preventing the expense title from remaining stuck on a placeholder. This improves the accuracy of expense data across all Odoo environments.
Original PR description
### Issue On Runbot, trial, and client databases, the automatic extraction of the description does not work when a user changes the database language When an expense is first generated up to 19.0, it…
### Issue
On Runbot, trial, and client databases, the automatic extraction of the description does not work when a user changes the database language
When an expense is first generated up to 19.0, it requires a name and is temporarily given a localized placeholder like "Dépense sans titre..." in French
When the OCR results arrive, the system is supposed to detect this generic fallback string and overwrite it with the real extracted description
However, because of a language mismatch, the system fails to recognize its own placeholder. It incorrectly assumes the user manually entered that text and, to prevent losing user data, refuses to replace it
Before the fix, the title remains stuck on the placeholder
In very rare cases, the translation applies correctly, but it fails most of the time
### Cause
The OCR successfully finds the correct description, but in `_fill_document_with_results`, the expense name is not replaced
This seems to happen because `self` in `self._get_untitled_expense_name("")` carries a residual context that could override the correct language to use during the automated extraction process
Even though the user record and the detected language are correctly set to the alternative language, `default_receipt_name` appears to be generated in English ("Untitled Expense")
This would cause the subsequent string comparison with the actual translated name stored in the database to fail, blocking the update
### Fix
I made some tests in some generated RunBot and the user is correct and also the associated lang
I supposed self was containing lang details overriding the correct language to use
`self.env['hr.expense'].with_context(lang=user_id.lang)` seems to be working
### Steps to reproduce
The issue cannot be reproduced locally, follow these steps on a Runbot instance:
- Retrieve IAP OCR credentials from a trial database
- Enable Developer Mode in Settings
- Go to Settings -> Technical -> IAP -> IAP Accounts
- Add the credentials for the Document Digitization service
- Go to the Expenses app
- Change the user's language to French
- Import the expense image from the ticket
- Open the newly created Expense and click Refresh
Before the fix, the title should stay `Dépense sans titre...` If it's not the case, try a second import, it works times to times
opw-6103935
Forward-Port-Of: odoo/enterprise#118661This update fixes an issue where the reconciliation reporting dialog was not displaying draft journal items, leading to an inaccurate count. By removing a default filter, the dialog now shows all matching items, providing a more complete and reliable reconciliation view. This improves the accuracy of financial reporting.
Original PR description
The reconcile badge counts draft and posted journal items, but the matching dialog forces a posted filter by default, this makes the dialog show fewer lines than count as it discards the draft ones. Remove the default posted search filter so the dialog displays all matching items. task-6234801
This update resolves an issue where project names weren't correctly synchronized with their linked folder names when multiple projects were edited simultaneously. The fix ensures that folder names are updated consistently during multi-editing operations, improving data accuracy and streamlining project management workflows.
Original PR description
Currently, when user multi-edits projects names from list view the linked folder name doesnt get updated. Steps to replicate: - Install `documents_project` and open projects. - Select multiple projects and edit their names. Issue: - The project names get updated but their respective linked folder's name doesnt get updated. Cause: - During multi-edit, `self.documents_folder_id` contains the folders of all selected projects. - As a result, `len(self.documents_folder_id.project_ids) == 1` [1] is evaluated on the combined recordset instead of per project, causing the condition to always fail when multiple projects are renamed. Solution: - Avoided accessing `self.name` on a `multi-recordset` during multi-edit. - Filtered projects individually and updated their document folders using the name in vals. [1]: https://github.com/odoo/enterprise/blob/3c2985ca6011700c271ed14e40e08c89be822753/documents_project/models/project_project.py#L101 sentry-7452096418
1 change
Resolved issues and error corrections
This update resolves an issue where validating rental transfers for new kit products resulted in an error message. The fix ensures that stock movements are correctly processed after a rental order is confirmed, specifically when a kit BOM is involved. This prevents data inconsistencies and ensures accurate tracking of rented items.
Original PR description
### Steps to reproduce: - Enable rental transfer - Create a rentable product R - Create and confirm a rental order for 1 unit of R - Create a kit bom for R: 1 x COMP - Validate the delivery of your…
### Steps to reproduce:
- Enable rental transfer
- Create a rentable product R
- Create and confirm a rental order for 1 unit of R
- Create a kit bom for R: 1 x COMP
- Validate the delivery of your unit of R
#### > Missing Error: Record does not exist or has been deleted.
### Cause of the issue:
Confirming your rental order will generate a confirm moves of R. However, since at this point the product was not a kit, these will not be exploded. Now, the issue is that at validation The move will be exploded and deleted in the super call:
https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/sale_mrp_renting/models/stock_move.py#L10-L13 https://github.com/odoo/odoo/blob/0f2f222a431627a672daf10c86ec2578a27f97bb/addons/mrp/models/stock_move.py#L550-L555 https://github.com/odoo/odoo/blob/0f2f222a431627a672daf10c86ec2578a27f97bb/addons/mrp/models/stock_move.py#L591-L593 However, since the overrides of the sale_{mrp,stock}_renting modules call self rather than the result of the super call, they still expect to work with the original move rather than its exploded result: https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/sale_mrp_renting/models/stock_move.py#L10-L13 https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/sale_stock_renting/models/stock_move.py#L61-L65
opw-61918411 change
Resolved issues and error corrections
This update resolves a display issue in translation mode where clicking carousel navigation buttons triggered an error message. The fix removes unnecessary HTML from attributes and ensures the buttons function correctly without disruptive notifications, improving the user experience during website translation.
Original PR description
## 1. Prevent toast on carousel nav buttons in translation mode [Commit 1] ### Steps to reproduce: 1. Go to Website -> Configuration -> Install another language. 2. Add the language to a website. 3.…
## 1. Prevent toast on carousel nav buttons in translation mode [Commit 1] ### Steps to reproduce: 1. Go to Website -> Configuration -> Install another language. 2. Add the language to a website. 3. Go to the website and drop a Carousel snippet. 4. Switch to the newly added language and enter Translate mode. 5. Click the carousel's "Next" or "Previous" arrow buttons. ### Issue: Clicking the buttons triggers "This translation is not editable." ### Cause: Carousel navigation buttons are wrapped in `<a>` tags with the `o_not_editable` class, which triggers the non-editable warning during translation mode. ### Solution: Ignore `.carousel-control-prev` and `.carousel-control-next` from triggering the translation error warning. ## 2. Strip translation HTML from attributes [Commit 2] When translating a website, attributes like `title`, `alt`, or `placeholder` on complex elements (elements containing children) or non-editable elements (e.g., carousel controls, search icons) display raw translation metadata (HTML spans) instead of the clean text. Steps to reproduce: 1. Install another language and add it to website. 3. Drop a Carousel snippet. 4. Switch to the new language and enter Translate mode. 5. Hover over the carousel arrows (next/previous). Issue: The tooltip displays raw HTML, `<span data-oe-translation-initial-sha=.. .>Next</span>`. Cause: This happens because attributes like `placeholder`, `title`, `alt`, `value` receive translation spans and the attribute cleanup logic had a strict filter (`:empty`, `input`...) that excluded elements containing other tags (like an `<a>` containing an `<i>` icon), so the raw translation HTML was never replaced with the clean value. Solution: This commit removes translation-specific HTML from the `title` attribute and keeps only the plain text. task:[4756921](https://www.odoo.com/odoo/project/974/tasks/4756921)