Daily updates from Odoo
Thursday, April 9, 2026
43 changes · saas-18.3
Resolved issues and error corrections
This update fixes an issue where sending letters with more than 8 pages would result in a generic error. The change provides a more specific error message to users, helping them quickly identify and resolve the problem when sending larger letters via snailmail. This improves the user experience and reduces support requests.
Original PR description
When a user attempted to send a letter with snailmail that had more than 8 pages, sending would fail, and a generic error message is logged on the letter. This commit makes the error message generated in that flow more specific to help users better understand the root cause of sending failure. task-5883011 Forward-Port-Of: odoo/odoo#257867
This update corrects a technical issue preventing Nilvera electronic invoices from importing correctly into Odoo. The method name in the Nilvera module was outdated, causing it to be ignored. By renaming the method to match the parent class, the import process is now functioning as intended.
Original PR description
# Description of the issue/feature this PR addresses The parent class `account.edi.xml.ubl_20` renamed `_import_fill_invoice_form` to `_import_fill_invoice`. The override in `l10n_tr_nilvera_einvoice` was not updated to match, causing the override to be silently ignored. # Current behavior before PR The `_import_fill_invoice_form` override in `l10n_tr_nilvera_einvoice` is never called because the parent method no longer exists under that name. # Desired behavior after PR is merged The override is renamed to `_import_fill_invoice` to match the parent class, restoring correct behaviour for Nilvera invoice imports. task-id: None --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258097
This update resolves an issue where duplicate checks were being generated during tax return creation, preventing users from generating returns. The fix ensures that only one check is performed for each return type, streamlining the accounting process and avoiding error messages.
Original PR description
Steps to reproduce:
- Go to Accounting → Configuration → Accounting → Return Types.
- Open the standard Annual Closing: Corporate Tax return type.
- Select Generic Tax Report as a report in the Report field.
- Navigate to Accounting → Accounting → Closing → Tax Returns.
- Generate the tax return for the selected period.
Issue:
- Duplicate checks with code check_draft_entries are created for the same return, raising:
'You can only have a unique check code for each return.'
This happens because:
- `_check_suite_common_vat_report` adds a Draft entries check.
- `_check_suite_annual_closing` also adds a similar check (No draft entries) with the same code.
- Both run together, causing duplication.
Solution:
- Added `check_codes_to_ignore.add('check_draft_entries')`
in _check_suite_common_vat_report to ensure the check is not generated twice.
opw-6066030This update resolves a technical issue that prevented the requirements-check script from correctly parsing package version numbers, specifically those with letters like 'post1'. This fix ensures accurate dependency checks, improving the stability and reliability of the Odoo system.
Original PR description
This commit fixes a crash in the parse_version() function where it doesn't support non-integer castable version parts (i.e. 5.4.2.post1). Forward-Port-Of: odoo/odoo#257946
This update resolves an issue where attendance records were incorrectly flagged as 'already checked-in' due to a timezone calculation error. The fix ensures accurate attendance tracking by correctly applying employee timezones during the absence detection process, preventing these erroneous alerts.
Original PR description
### Steps to reproduce: - Have a database in timezone America/Asuncion for example - Create an employee - Create an attendance for the day before yesterday from 13h to 19h - Run the absence detection cron - An error will be raised saying the user is already checked-in on that day ### Cause: When trying to create an absence attendance we localized yesterday's midnight into UTC and then apply the employee timezone. Which cause a one-day shift when having a timezone behind UTC as at that point we try to create an attendance on the day before yesterday not yesterday ### Fix: We use the timezone of the employee to localize midnight then get this time in UTC. opw-5930309 Forward-Port-Of: odoo/odoo#257932
This update resolves an issue where negative values in the Mod 390 tax report for Spain were not being properly marked with the 'N' indicator, as required by Spanish tax regulations. The fix adds a necessary parameter to ensure accurate reporting, aligning with official documentation and improving compliance.
Original PR description
### Issue: Negative values in the Mod 390 report were not properly marked with the N indicator for several fields ### Cause: The parameter `signed=True` was missing on some fields where negative…
### Issue: Negative values in the Mod 390 report were not properly marked with the N indicator for several fields ### Cause: The parameter `signed=True` was missing on some fields where negative values should include the N indicator in the BOE export ### Note: According to the official specification, negative amounts must be explicitly marked with N Latest documentation: https://sede.agenciatributaria.gob.es/static_files/Sede/Disenyo_registro/DR_300_399/archivos_25/dr390e2025.xlsx ### Steps to reproduce: - Install `l10n_es_reports` with demo data and switch to the ES company - Create a Bill (Price: 100, Taxes: 21% G) - Go to Tax Report and select Tax Report (Mod 390) (ES) for the full year - Open the VAT Deductible tab - The last line (65) should be negative - Export the BOE file using the gear menu - Check the last value of section 4 in the file ### Before the fix: Negative values were not marked with N opw-5482706 Forward-Port-Of: odoo/enterprise#113200 Forward-Port-Of: odoo/enterprise#111262
This update fixes a problem where users weren't receiving clear error messages when the delivery service failed. A helpful hint has been added to the delivery process, guiding users to resolve the issue and ensuring smoother delivery operations. This change improves the user experience and reduces potential delays.
Original PR description
Add hint with error message. ----- Ticket: opw-6072855 Forward-Port-Of: odoo/enterprise#112463
This update resolves issues where URLs were incorrectly converted to links and where backticks were included in pasted URLs. The changes ensure that URLs are handled accurately, preventing unwanted link transformations and preserving pasted URL formatting, improving the note-taking experience.
Original PR description
[FIX] html_editor: undo link autoconvert before space insertion When adding a space after an URL, the URL text is converted to an URL. When pressing undo, first the space is undone, then the link is…
[FIX] html_editor: undo link autoconvert before space insertion When adding a space after an URL, the URL text is converted to an URL. When pressing undo, first the space is undone, then the link is undone. This is wrong because if the user did not want a link, after undoing the link, inserting a new space will again convert to a link. This commit splits `handleAutomaticLinkInsertion` into two parts: determining if a link must be created, and actually inserting the link. This makes it possible to execute code within the condition before and after the insertion. To fix the similar behavior for enter and shift-enter, another before input handler is also added in order to let the default before input be executed before creating the link. Steps to reproduce: - Go to a "To do" note - Type "odoo.com" - Press space/enter/shift-enter - Undo a single time => The insertion was undone instead of the link transform. task-5936310 [FIX] html_editor: not include surrounding backtick in pasted URL When pasting an URL surrounded by backticks, the ending backtick is included inside the link's HREF. This commit fixes the regex for URL to also exclude backticks (like it did with `"` and `'`). Steps to reproduce: - Copy the following text in the clipboard: ``` `odoo.com` ``` - Go to a "To do" note - Paste => The link's URL was ``` odoo.com` ``` task-5936310 Forward-Port-Of: odoo/odoo#257647 Forward-Port-Of: odoo/odoo#248619
This update addresses a technical issue where delivery confirmations were failing due to missing tracking data. The fix ensures that picking validation occurs correctly and prevents shipping creation in Easypost when tracking information is unavailable. Easypost support suggested a slight delay between order placement and tracking retrieval as a potential workaround.
Original PR description
Problem: 'tracker' object in response from GET /orders/:id request can sometimes be null. This means that when the mail template 'mail_template_data_delivery_confirmation' is sent, a traceback occurs…
Problem: 'tracker' object in response from GET /orders/:id request can sometimes be null. This means that when the mail template 'mail_template_data_delivery_confirmation' is sent, a traceback occurs with error: TypeError: 'NoneType' object is not subscriptable. As a result the picking is not validated in odoo but a shipping has succesfully been created in the easypost backend. Solution: Prevent traceback form happening, picking gets correctly validated and carrier_tracking_url field is empty. Transcript from Easypost support: << I'm also seeing the tracker showing as null when reviewing the response. I'll go ahead and create a ticket for the engineering team to investigate. I can see that the tracking code is being returned in the request, but the full tracking object is not. Since this appears to be happening on a case-by-case basis, you may want to allow more time between the BUY and the GET requests, as I noticed they are being triggered very close together. I'm not certain if that's related, but it may be worth trying as a troubleshooting step while we have this under review. >> opw-5402415 Forward-Port-Of: odoo/enterprise#111833
This update resolves an issue where closing a session was blocked when generating the DSFinV-K export if the order's user information was missing. The change ensures that a fallback user ID is used, allowing sessions to be closed correctly. This improves session management stability.
Original PR description
Before this commit, closing a session was blocked if an order was missing the user_id field during DSFinV-K export generation. opw-6067382 Forward-Port-Of: odoo/enterprise#112119
This update fixes a potential issue where invoicing a Point of Sale order multiple times could create unnecessary stock pickings. Previously, clicking 'Invoice' repeatedly would generate extra stock movements, especially with our 'Anglo-Saxon' accounting settings. This change ensures that pickings are only created once, streamlining inventory management.
Original PR description
Calling `action_pos_order_invoice` on an already-invoiced POS order (e.g. a backend user clicking "Invoice" more than once) would unconditionally invoke `_create_order_picking`, producing one extra `stock.picking` per click under anglo-saxon + update_stock_at_closing configurations. opw-6092999 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257509
This update resolves a memory issue that caused server crashes when calculating cumulated balances for large accounting records. The fix optimizes the query process to only retrieve necessary data, significantly reducing memory usage and improving performance. This enhancement ensures smoother operation for systems handling extensive transaction data.
Original PR description
The _compute_cumulated_balance() method performs a query over every existing move lines to get a dict associating the record id with the cumulated sum at this point. When there is a lot of move…
The _compute_cumulated_balance() method performs a query over every existing move lines to get a dict associating the record id with the cumulated sum at this point. When there is a lot of move lines, the result returned by fetchall() hits the memory limit and the server crashes. We propose to encapsulate the original query to only return the result for the account move lines present in self. Benchmarks --------------- The following benchmarks were generated with a customization of the account.move.line list view to display the cumulated_balance field. Memory usage during the self.env.cr.execute and the dictionary population: | Operation | Before the fix | After the fix | |---------------|----------------|---------------| | populate dict | 1.5 GB | 17.1 MB | | execute query | 430 MB | 8.3 MB | 100 000 lines were displayed at the same time to get a significant size. So the number of records in self is more than 7 000 000 without the fix and 100 000 with the fix. Time spent in the _compute_cumulated_balance method: | No of AML | Before the fix | After the fix | |-----------|----------------|---------------| | 7 000 000 | 10.4 s | 6.8 s | opw-6053720 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256658 Forward-Port-Of: odoo/odoo#255780
This update corrects a technical issue preventing SEPA payments from being correctly exported to XML files. The fix replaces problematic '&' characters in payment references with '+' to ensure compliance with SEPA/SIX standards and avoid rejection by banks. This ensures smooth processing of international payments.
Original PR description
Steps to reproduce: 1. Install modules `account_batch_payment` and `l10n_ch`. 2. Configure SEPA Credit Transfer for a CH company. 3. Create a vendor bill with a reference containing `&` (e.g. "Net &…
Steps to reproduce: 1. Install modules `account_batch_payment` and `l10n_ch`. 2. Configure SEPA Credit Transfer for a CH company. 3. Create a vendor bill with a reference containing `&` (e.g. "Net & Cost"), confirm it and register a payment using SEPA Credit Transfer. 4. Create a batch payment with the SEPA payment and validate it. Issue: The `&` character is exported as `&` in the generated PAIN XML, while according to the SIX specification it should be replaced with `+` Cause: The payment reference is inserted into the PAIN XML file without replacing the '&' character. During XML generation this produces an invalid entity (`&`) which results in an `XMLSyntaxError` and prevents the payment file from being processed. Solution: Replace the `&` character with `+` when sanitizing the payment communication so that the generated value complies with the SEPA/SIX character set and produces valid XML. Reference[Pg: 9]: https://www.europeanpaymentscouncil.eu/sites/default/files/KB/files/EPC217-08%20Draft%20Best%20Practices%20SEPA%20Requirements%20for%20Character%20Set%20v1.1.pdf opw-5941724 Co-authored by @bhra-odoo Forward-Port-Of: odoo/enterprise#110809
This update resolves an issue where empty attachments in PEPPOL invoices could cause import failures. The fix automatically uses default journal and move type information if an attachment is missing, ensuring invoices are created and any errors are logged. The underlying cause of the empty attachments is still being investigated.
Original PR description
Empty attachments could crash parsing during import, this commit falls back on default journal and move type in case of error, allowing the invoice to be created and the issue logged properly. Root cause of empty XML remains unclear, likely a 3rd party error. opw-6060739 opw-6018364 Forward-Port-Of: odoo/odoo#256011
This update fixes an issue where the formatting toolbar would unexpectedly open when working with inline code. Now, formatting commands are correctly applied only to the text surrounding inline code, and pasted HTML is properly converted to plain text within inline code blocks. This ensures a smoother and more reliable editing experience.
Original PR description
### Purpose of this commit: - Prevent the powerbox and toolbar from opening when the selection is fully inside inline code. When the selection spans inline code and regular text, keep the toolbar visible but ensure formatting commands are applied only to the non-inline-code content. - Ensure that pasted external and editor HTML is converted to plain text when inserted inside inline code. task-5502939 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258039 Forward-Port-Of: odoo/odoo#250911
This update fixes an issue where invoices for downpayments weren't using the intended expense account (ACC1). The change ensures that the correct account is automatically suggested when creating invoices for downpayment products, streamlining the accounting process and preventing errors. This improves accuracy in financial reporting.
Original PR description
Steps to reproduce: 1/ install purchase and accountant 2/ create and setup an expense account dedicated to your downpayments (typically code 60-, account type "expense"), ACC1. 3/ setup a service type product named "downpayment" 4/ set the default expense account on that product to be ACC1. 5/ create a PO for any product other than the downpayment (PO1). take note of the partner. 6/ create a bill for the same partner as the one set on PO1. Call it BILL1. 7/ On BILL1, add one invoice line with the "downpayment" product. Set a unit price. 8/ Confirm BILL1 and match it with PO1 via the "bill matching" smart button. Add it as a downpayment. 9/ Back on PO1, receive the products. Create a bill (BILL2). => The account suggested for the downpayment line in BILL2 will use the default expense account instead of ACC1. After this commit, the account suggested will be the one used in BILL1 for the downpayment line. opw-5253877 Forward-Port-Of: odoo/odoo#245518
This update ensures seamless invoice processing for our Polish customers by automatically renewing the KSeF (tax) tokens. Previously, expired tokens caused disruptions in bill retrieval and invoice sending, requiring manual user intervention. Now, a scheduled task refreshes the tokens every 6 days, maintaining uninterrupted synchronization with the Polish tax authority.
Original PR description
The KSeF refresh token issued by the Polish Ministry of Finance expires after a week. Once it expires, the automatic fetching of incoming bills and sending of invoices will fail until the user manually re-authenticates in the settings. To ensure uninterrupted synchronization with the KSeF API, this commit adds a new scheduled action that runs every 6 days to automatically renew the tokens. task-6041758 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#256700
This update fixes a display issue in delivery reports where backorder lines were missing their unit of measure. The fix removes a technical restriction that previously hid this information, ensuring all line items, including backorders, accurately show their units. This improves clarity and accuracy for users reviewing delivery reports.
Original PR description
**Steps to reproduce:** * Install the **Stock** module with demo data. * Create a delivery with quantity **N** and click **Mark as To Do**. * Set the delivered quantity to less than the demanded…
**Steps to reproduce:**
* Install the **Stock** module with demo data.
* Create a delivery with quantity **N** and click **Mark as To Do**.
* Set the delivered quantity to less than the demanded quantity .
* Validate the delivery, with the creation of a **backorder**.
* Print the **Delivery Slip** report.
**Observed behavior:**
* Backorder lines appear **without units of measure**, while
other lines correctly display their units.
**Cause:**
* The backorder line includes a **group restriction** that hides
the unit unless the *Unit of Measure* setting is enabled.
**Fix:**
* Remove the group restriction so units of measure are
always visible on backorder lines same as others.
<details>
<summary>Click here to see the results:</summary>
Before:
<img src="https://github.com/user-attachments/assets/5f21139a-a4ab-4c39-8b16-3c68c94a163e" />
After:
<img src="https://github.com/user-attachments/assets/dd4de18b-dc2e-4686-8435-30864fe40aa4" />
</details>
---
> NOTE - This fix done after receiving confirmation from PO(dala)
---
opw-5265051
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#257108
Forward-Port-Of: odoo/odoo#238470This update ensures CSV files are now correctly recognized as viewable within Odoo's list views, mirroring the behavior in the Kanban view. This change provides a more consistent user experience and allows users to easily access and work with CSV data directly from list views.
Original PR description
Current behavior before PR: - CSV files were viewable from the Kanban view, and opened the spreadsheet conversion dialog - In list view, CSV files were not considered viewable - Same issue for trashed CSV files in list view Desired behavior after PR is merged: - Consider CSV files as viewable in list view - Align behavior with the Kanban view Task: 6052134 Forward-Port-Of: odoo/enterprise#112869
This update resolves an issue where the 'Export XML' button was incorrectly disabled in the account management interface. Following a recent UBL export refactor, the button was removed from the list view. This change ensures the button appears only when an export is actually possible, improving usability and accuracy.
Original PR description
Problem --------- Since the UBL export refactor, it was not possible to export the XML of non-imported bills and not self-bills. The Export XML option had been removed from the list view in odoo/odoo#255289. The Form view was omitted. Solution --------- Show the button "Export XML" only if the move can actually be exported. opw-6083344 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a technical glitch that prevented the automated tour generation feature from working correctly. The fix, identified by runbot issue 242264, ensures that the tour consistently runs as expected, improving the user experience. This change primarily impacts the industry_fsm module.
Original PR description
runbot issue-242264
This update resolves an issue where FSM users couldn't access the Bill of Materials (BOM) when managing stock moves within service tasks. The fix grants necessary BOM access to project users, ensuring FSM staff can correctly handle stock movements related to service orders. This improves the efficiency of service operations.
Original PR description
**Steps to reproduce:**
- Install mrp, industry_fsm_repair, and industry_fsm_sale
- Create a user with only fsm access rights
- Create a sale order with both service and goods products using the above user
- Confirm the sale
- Log in as the fsm user
- Go to fsm app > open task > open pickup > open stock move
**Issue:**
fsm users with no BOM access encounter errors when opening stock moves from fsm tasks.
**Cause:**
lack of bom access for fsm-only user.
**Fix:**
This commit grants bom and bom line access to the project user.
task-5077522This update fixes an issue where the portal displayed inflated timesheet totals by including hours from both parent and sub-tasks. Now, the portal accurately reflects the total time spent on a project, providing a clearer view for customers. This ensures accurate reporting and avoids confusion.
Original PR description
Steps to Reproduce: - 1. In the Project app, create a new project and enable "Timesheets". 2. Create a parent task with allocated hours (e.g., 20h). 3. Create one or more sub-tasks under the parent,…
Steps to Reproduce: - 1. In the Project app, create a new project and enable "Timesheets". 2. Create a parent task with allocated hours (e.g., 20h). 3. Create one or more sub-tasks under the parent, also with allocated hours (e.g., 8h and 5h). 4. Log in to the portal and navigate to the project's task list. 5. Observe the "Total" allocated time shown in the list header. Issue: - - The total allocated time displayed in the portal incorrectly sums the hours of the parent task and all its sub-tasks (e.g., 20h + 8h + 5h = 33h). This leads to an inflated and confusing total for the customer. Cause: - - The `_get_portal_total_hours_dict` method calculated the sum of `allocated_hours` on the entire recordset of tasks passed to it, without distinguishing between parent tasks and their children when both were present. Fix: - - This commit excludes sub-task hours from the total allocated time computation if their parent task is also present in the view. - The total time spent now uses parent `total_hours_spent` which includes both time spent on parent and sub-task. task-4939234
This update resolves a test failure within the Odoo Enterprise accounting module. The issue stemmed from incorrect data values during testing, specifically related to payment processing and multi-bill statements. This fix ensures the test runs successfully, maintaining the stability of the accounting functionality.
Original PR description
Fixup for test test_early_payment_discount_multi_bill_statement that will fail when accountant is not installed due to mismatched amls values opw-5881976
This update ensures that live chat agents can always see and use the button to initiate new conversations while participating in active live chats. Previously, agents couldn't start new chats when already engaged. This improvement streamlines the live chat workflow for agents and visitors.
Original PR description
Previously, users who were part of active livechats as agents could not see the livechat button to start a new conversation. This change ensures the button remains visible so users can start additional livechats as a visitor. task-[5119098](https://www.odoo.com/odoo/project/1519/tasks/5119098)
This update resolves an issue where the department dropdown was empty in the demo activity plan, even when departments existed. The fix corrects a configuration error that was preventing the system from correctly associating departments with the demo plan. This ensures users can properly assign departments when setting up onboarding or offboarding activity plans.
Original PR description
# How to reproduce - Be in a single company environment - Employees app > Configuration > Activity Plan > Either demo plan (Onboarding or Offboarding) - Try to select a department # The problem The…
# How to reproduce - Be in a single company environment - Employees app > Configuration > Activity Plan > Either demo plan (Onboarding or Offboarding) - Try to select a department # The problem The dropdown is empty even if department exists. This can be check by creating a new plan and trying to assign departments to it. # Cause The demo data for thoses two plan explicitely sets the company_id to false : https://github.com/odoo/odoo/blob/2c14ce9f655a1eea3d7b1cb0e0ce8108cf9da0df/addons/hr/data/hr_data.xml#L21 https://github.com/odoo/odoo/blob/2c14ce9f655a1eea3d7b1cb0e0ce8108cf9da0df/addons/hr/data/hr_data.xml#L48 But the department_id has check_company set to true : https://github.com/odoo/odoo/blob/2c14ce9f655a1eea3d7b1cb0e0ce8108cf9da0df/addons/hr/models/mail_activity_plan.py#L12 # Proposed solution Backport of this commit : https://github.com/odoo/odoo/pull/240167 opw-6058697 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255842
This update fixes an issue where users couldn't insert snippets into website forums by clicking on snippet groups. The fix allows snippet group clicks, treating them as a fallback option when other dropzones are unavailable, ensuring snippet insertion remains functional. This improves the user experience for forum content creation.
Original PR description
Steps to reproduce the issue: - Go to Forum, then go to the Help page - Enter Edit mode - Try to drag and drop a snippet => The dropzone in the s_cover at the top of the page are available - Try to click on a snippet group => Nothing happen, because all dropzones are filtered The s_cover element has the [data-snippet] attribute. When clicking on a snippet group, the editor filters out dropzones inside other snippets. Since s_cover is treated as a snippet, its dropzones are excluded, even though they are the only ones available on the page. The solution is to treat dropzones inside snippets as low priority instead of strictly forbidden. If no other valid dropzones exist, we allow these as a fallback to ensure snippet insertion remains possible. task-5938138 Forward-Port-Of: odoo/odoo#256078
This update resolves an issue where users could encounter access rights errors when creating email campaigns with dynamic fields. The fix prevents a style attribute from being added to `<t>` nodes during the inlining process, addressing a conflict with permission checks. This ensures smoother campaign creation for all users.
Original PR description
This commit fixes an unexpected access rights error when users try to add simple dynamic fields allowed by mail_allowed_qweb_expressions to mass_mailing emails. During the convert_inline process, the…
This commit fixes an unexpected access rights error when users
try to add simple dynamic fields allowed by mail_allowed_qweb_expressions
to mass_mailing emails.
During the convert_inline process, the <t t-out=""/> placeholder element
has its style inlined, and attributed to its style attribute.
This style attribute was not filtered out during the safety
check process, resulting in the templating engine believing a disallowed
directive was used.
Steps to reproduce:
- On a fresh 18.0+ install with demo data, login as Marc Demo
- Access the Email Marketing app
- Create a new mailing campaign
- Set sending to Newsletter or Mailing Contact
- Type /field to add a dynamic value
- Set it to Name
- Save the mailing
- An access rights error is raised due to the user not having
group_mail_template_editor permissions and the dynamic placeholder
node having a style attribute
Fix:
T nodes are no longer granted a style attribute during style inlining.
Forward-Port-Of: odoo/odoo#226111This update fixes an issue where pressing 'Enter' in a toggle list would create a duplicate list instead of removing the existing one. Now, when a toggle block with formatting is entered, it correctly removes the block and exits the list. Additionally, a fix was implemented to preserve the direction attribute when entering a toggle block, ensuring RTL formatting is maintained.
Original PR description
**Current behavior before PR:** Steps to reproduce issue: - Create a toggle list. - Apply some formattings e.g. bold and italic to title. - Press Enter. Instead of removing the toggle, another toggle list is created. **Desired behavior after PR is merged:** Now, if there is a empty toggle block title having some formattings in it, pressing enter removes the empty toggle and exit the list. task-6075014 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256355
This update fixes a problem where sale orders for partners with SEZ GST treatment incorrectly defaulted to the 'Export' fiscal position. The change ensures the correct 'Foreign State' fiscal position is selected, accurately reflecting the partner's location and GST requirements. This improves the accuracy of sales reporting and compliance.
Original PR description
Before this commit: When creating a sale order, if the GST Treatment of partner is SEZ, then the Fiscal position is set as Export instead of SEZ. Reason: The default `foreign_state` obtained currently is searched on base of state whose country is not India, so any random state is fetched. But in the fiscal position of SEZ, we want "Foreign State", so while selecting fiscal position from `_get_fiscal_position` method, the Export fiscal gets higher ranking and gets selected. This commit fixes this issue by returning the correct Foreign State if fiscal position is set to SEZ. task-5958903 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254887
This update fixes an issue where refunds weren't properly accounted for when calculating outstanding customer dues in the Point of Sale system. Previously, only regular orders were considered, leading to inaccurate due amounts. Now, refund orders with negative totals are included, ensuring correct due calculations and a more reliable user experience.
Original PR description
Step to reproduce - install "pos_settle_due" - have a customer, A and a pos with payment method "customer Account" - start pos, add 3 qty of product with unit price 10$ with partner A - use payment method "customer Account" i.e. of type "pay_later" (do not invoice orders) - refund 1 qty of previous order using same payment method - go to partner list, notice A has 20$ as due - click on "hamburger btn" > settle due amount Observation: - notice we only get the order amount as due i.e order with 30$ - we should have received the refund order too, so that net due of 20$ can be processed Cause: - currently, we didn't considered refunds orders at all, when settling dues Fix: - now we consider order with total < 0 i.e refund orders to be included for settlement opw-5869313 Forward-Port-Of: odoo/enterprise#107883
This update resolves an issue where the employee sick leave warning incorrectly flagged employees with long absences before 31 days. The fix now accurately identifies employees who have been on sick leave for at least the past 31 days, ensuring more accurate reporting and compliance. This improves the reliability of HR data.
Original PR description
-**Issue**: The warning shows employees who had a long sick leaves before 31 days, which is incorrect. -**Fix**: Adjust the logic to include employees who have been on a sick leave for the past 31 days (at least). Forward-Port-Of: odoo/enterprise#113249 Forward-Port-Of: odoo/enterprise#112985
This update fixes an issue where the total sales figures displayed on event pages were incorrect when sales were made in currencies other than the company's default currency. The code has been updated to accurately convert sale prices from the event's currency to the company's currency, ensuring correct totals are shown. This improves the accuracy of financial reporting for events.
Original PR description
Steps to reproduce: 1. Create a currency with a non-1 exchange rate with the company's currency (e.g. VEF with a rate of 0.000005 against USD). 2. Create a pricelist in that currency. 3. Create an…
Steps to reproduce: 1. Create a currency with a non-1 exchange rate with the company's currency (e.g. VEF with a rate of 0.000005 against USD). 2. Create a pricelist in that currency. 3. Create an event. 4. Create a sale order with the new pricelist. 5. Add a sale order line with a ticket of the event and confirm the order. 6. Go to the event's page and check the total sales smart button. 7. Check the total sales of the event: it should be equal to the sale order's total price converted to the company's currency, but it is not, because of the wrong conversion (it used the inverse of the correct exchange rate, which is 200000 instead of 0.000005 in our example). Problem: The total sales smart button in an event's page shows wrong totals when sales are in a currency other than the company's currency. Cause: The code converts the sale price from the event's currency (which is the same as the company's currency) to each sale order's currency, while it should be the other way around (from each sale order's currency to the event's currency). https://github.com/odoo/odoo/blob/3cd709172e997f5a726cf3ae85ffcb9965619fcb/addons/event_sale/models/event_event.py#L38 opw-5494790 Forward-Port-Of: odoo/odoo#257818 Forward-Port-Of: odoo/odoo#253605
This update fixes an issue where draft stock moves were incorrectly flagged as unavailable, even when sufficient stock existed. The fix adjusts how availability is calculated to accurately reflect available quantities, ensuring accurate forecasting and preventing order fulfillment problems. This improves the reliability of stock management.
Original PR description
Steps to reproduce: - Create a storable product "P1" - Update on-hand quantity to 2 units - Create a delivery with 2 units of P1 and keep it in draft state Problem: The forecast availability is…
Steps to reproduce: - Create a storable product "P1" - Update on-hand quantity to 2 units - Create a delivery with 2 units of P1 and keep it in draft state Problem: The forecast availability is displayed in red (not available), even though the stock is sufficient to fulfill the move. Explication: For draft consuming moves, the forecast availability is computed as: `virtual_available - move.product_qty` In the case where stock exactly matches the demand, this results in 0. However, on the JS side, availability is evaluated with: `forecast_availability >= product_qty` So with forecast_availability = 0 and product_qty = 2, the condition evaluates to False, incorrectly marking the move as not available. https://github.com/odoo/odoo/blob/c7fede7f44c668ccc0a094d8341c3cae8879a7f1/addons/stock/static/src/widgets/forecast_widget.js#L31 Solution: When the available quantity is sufficient to cover the move (using float_compare), set forecast_availability to the full available quantity instead of subtracting the move quantity. This ensures the JS condition correctly evaluates to True and the move is marked as available. opw-5159142 Forward-Port-Of: odoo/odoo#257354
This update fixes an issue where marketing emails sent in RTL languages (like Arabic) were incorrectly displayed in a left-to-right format. The fix ensures that RTL content is properly formatted by adding the 'direction' style to the allowed CSS, improving the user experience for international customers. This resolves a bug impacting campaign delivery and presentation.
Original PR description
**Steps to reproduce:** - Install Mail Marketing app - Change user language to a RTL language (such as Arabic) - Create a marketing campaign with RTL content - Send it (with the campaign, test mail works properly) - Mail received changes from RTL to LTR **Issue:** Table `direction` style is removed by the `_Cleaner` as it is not in its `_style_whitelist` during the composer creation. **Fix:** Add it to the valid styling to ensure rtl mails are properly formatted by the rtlcss library. related fix: https://github.com/odoo/odoo/commit/4ac3766fa5b458864c1728441cf4a157df943d39 sanitize on `mail.composer.mixin`: https://github.com/odoo/odoo/commit/24731938f75358fd3c72b91465b72ab80d62d208 opw-5982854 Forward-Port-Of: odoo/odoo#257886
This update fixes a minor issue within the HTML editor that prevented proper handling of textareas. The change backports a previously developed fix from another Odoo version, ensuring textareas within the editor function correctly. This improves the overall stability and usability of the HTML editor.
Original PR description
Before this commit: in #253638 we override the focus function of the editable to focusEditable. A patch for textarea and resetting the focus function at destroy is introduced at the forward port 19.0. After this commit: we backport the patch from c9c2325a966db5abf61810000234042f45ef1728 task-6034339 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257481
This update ensures that refused time off requests are now clearly marked on the calendar view within the Overview menu. Previously, these requests weren't visually distinguished. This change improves clarity and accuracy for HR staff when reviewing employee time off schedules.
Original PR description
Before this commit, the calendar view in Overview menu does not strike the time off refused. The reason is because `is_strike` field is not fetched inside that view. This commit adds the field in the view to make sure the time off refused are striked as it is the case in the other menus. Closes #248868 Forward-Port-Of: odoo/odoo#256723 Forward-Port-Of: odoo/odoo#256579
This update fixes a bug where accrual calculations weren't working correctly for allocation plans that used modes other than 'By Employee'. The change ensures that allocation durations are automatically calculated accurately, regardless of the chosen allocation mode, improving the reliability of holiday accruals. This impacts all users who utilize the holiday accrual functionality.
Original PR description
### Steps to reproduce: - Create an accrual plan of one level to give 20 days at the start of the year - Create an allocation with different mode than 'By Employee' - Set the accrual plan for the…
### Steps to reproduce: - Create an accrual plan of one level to give 20 days at the start of the year - Create an allocation with different mode than 'By Employee' - Set the accrual plan for the allocation and date from 1st Jan - Notice the Allocation number of days doesn't get automatically calculated ### Cause: This is happening because when trying to process the accrual plan we won't have any records in the field employee_id https://github.com/odoo/odoo/blob/bcdd12d13d73915e565fd2c8478b936a16efb9f4/addons/hr_holidays/models/hr_leave_allocation.py#L892-L893 And since employee_id is computed field when computing it we don't handle the case of any other mode other than 'By Employee'. https://github.com/odoo/odoo/blob/bcdd12d13d73915e565fd2c8478b936a16efb9f4/addons/hr_holidays/models/hr_leave_allocation.py#L259-L270 ### Fix: If we have different mode in the allocation we fetch the employees in this mode (Department, Company, Employee Tag) and set them as the allocation employee_ids so when computing the employee_id we will have a record in the field and it won't be null P.S. In the forward port we will have to introduce another fix for the multi allocation wizard opw-5888023 Forward-Port-Of: odoo/odoo#257683 Forward-Port-Of: odoo/odoo#247091
A bug was preventing users from deleting timesheets when a confirmation dialog was open. Pressing the Enter key would incorrectly start/stop the timer instead. This update ensures the Enter key correctly triggers the delete confirmation, resolving a frustrating user experience.
Original PR description
When a delete confirmation dialog is open in the timesheet list view, pressing Enter starts/stops the timer instead of confirming the dialog. This happens because the timer's window keydown handler does not check for active modals before intercepting the Enter key. Add a `.modal` check consistent with the grid renderer's onKeyDown. Steps to reproduce: 1) Open timesheet list view 2) Select a record and delete it 3) When the confirmation dialog opens, hit ENTER key Current behavior: The Timer starts recording timesheet Expected behavior: The record should be deleted For ref: https://youtu.be/tzm_3RNe1ig Forward-Port-Of: odoo/enterprise#112583
This update resolves an issue where deleting a public holiday incorrectly created timesheets for all related leave requests, even those that were refused. Now, deleting or modifying a holiday will only generate timesheets for valid, approved leaves, streamlining the timesheet process and preventing unnecessary entries.
Original PR description
…d leaves Description of the issue/feature this PR addresses: When a public holiday is edited or deleted, the timesheet re-creation is erroneously done for *all* leaves, even those which are canceled or still in draft. Steps to Reproduce: 1. Create a Time Off request for a timesheet-creating leave type (i.e. `timesheet_generate = True`) that overlaps with a public holiday. 2. Refuse the Time Off request. 3. Delete the public holiday the request overlaps with. Current behavior before PR: The deletion of the holiday causes timesheet entries to be created, even though it's a refused request. Desired behavior after PR is merged: The deletion or editing of the public holiday only re-creates the timesheets for the leaves that are actually valid and thus need timesheet entries. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255155 Forward-Port-Of: odoo/odoo#250372
This update ensures that archived product filters in the Odoo dashboard work correctly. Previously, the system incorrectly filtered out archived products, preventing them from appearing in spreadsheet global filters. This change resolves this issue by correctly loading display names for archived records, improving filter functionality.
Original PR description
## Description: Steps to reproduce: - Open Dashboard > Sales > Sales. - Search for an item to filter. - Click the "Product" filter. - Click "Search more". - Search for an archived product. - Select it to add it to the filter. Issue: The filter needs `nameService.loadDisplayNames()` to resolve the label of the selected record ids. In 17.0, that service calls `webSearchRead()` without `active_test=False`, so archived records are filtered out and treated as missing. This makes spreadsheet global filters fail on archived records. Fix: Fetch display names with `active_test=False` in the shared web `nameService`, so already-known archived record ids can still be resolved. Task: [6094596](https://www.odoo.com/odoo/project/2328/tasks/6094596) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258113 Forward-Port-Of: odoo/odoo#257534
This update ensures that new purchase orders, repairs, and stock picking batches display translations correctly, matching the standard 'SO' logic. Previously, these records showed 'New' in English, which could confuse users. This change improves the user experience and consistency across Odoo.
Original PR description
New POs, repairs, and batch pickings always showed "New" in English for the name of a new (not saved) record. We now make it match the SO logic to show up as translated so as to not confuse users (even though it will automatically change to another name once saved) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258156
Features or functions removed from Odoo
This pull request removes a mistakenly added translation file for the website_twitter module. The translation was previously introduced in a different pull request and has now been corrected. This ensures the website's internationalization is accurate and consistent.
Original PR description
Wrongly added in https://github.com/odoo/odoo/pull/172269. Module was deleted in https://github.com/odoo/odoo/pull/172755. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257859