Daily updates from Odoo
Thursday, January 15, 2026
198 changes
49 changes
Resolved issues and error corrections
This update resolves a random failure in a key stock management tour. The issue stemmed from a timing conflict during the unpacking of pallets, leading to incomplete actions. The fix adds a verification step to ensure the first pallet line is fully unpacked before proceeding, improving tour reliability.
Original PR description
Before this commit, the tour `test_internal_picking_reserved_move_packages_into_new_palet` was randomly failing. In this tour, we have two palets we unpack. The issue is, after unpacked the first one, we complete the second one line and then we unpack it. But it can happen the click on the button to complete the second line was done too quickly (in the meantime the first palet line is unpacked) and thus, because of this race condition, the second palet line was not complete (either it's just a visual bug due to a refresh in the wrong time, either the complete action is dropped due to the first line unpacking action.) To fix that, this commit adds a step to verify the first line is correctly unpacked before going further. runbot-build-error: [237801](https://runbot.odoo.com/odoo/runbot.build.error/237801) Forward-Port-Of: odoo/enterprise#104261
This pull request addresses a technical update to the Belgian payroll module (l10n_be_hr_payroll) to align with recent refactoring efforts. The change ensures accurate processing of DmfA declarations, maintaining the correct functionality for payroll calculations in Belgium. This update is a routine maintenance fix.
Original PR description
Forward-Port-Of: odoo/enterprise#104175
This update ensures that the DDT number is correctly included in delivery reports sent to customers. Previously, the DDT number was missing from the attached PDF, causing confusion. The fix changes the process to generate the DDT number before sending the email, resolving this issue.
Original PR description
When validating a delivery, Odoo did not include the DDT number in the report, as it was generated after rendering the PDF/email. This fix changes the order to generate the DDT number before sending…
When validating a delivery, Odoo did not include the DDT number in the report, as it was generated after rendering the PDF/email. This fix changes the order to generate the DDT number before sending the email. Steps to reproduce: - Create a database with an Italian company and the `l10n_it_stock_ddt` module installed - Turn on `Settings > Inventory > Shipping > Email Confirmation` - Under `Settings > General Settings > Companies > Email Templates` click `Review all Templates` - Edit the `Shipping: Send by Email` template - Under the `Settings` tab, you find the `Dynamic reports` field (which is a `many2many`), add the `DDT report`. - Create a SO, validate it - On the top of the SO, you see the delivery button with one delivery, click it, then validate the delivery. - In the chatter you see the message that was sent, with the `DDT report` PDF attached, with `False` instead of the DDT name. - If you open the report, the title of the PDF is also missing the DDT name. Ticket [link](https://www.odoo.com/odoo/project.task/5364265) opw-5364265 Forward-Port-Of: odoo/odoo#243492
This update fixes a problem where incorrect credentials caused misleading error messages when sending invoices. The change adds a test to ensure the correct error is displayed, preventing confusion and ensuring invoices are processed properly. This improves the reliability of the HR EDI module.
Original PR description
Fixing incorrect error display that occurred while trying to send an invoice to MER with incorrect credentials set up. (no task/error ID) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243745 Forward-Port-Of: odoo/odoo#243489
This update automatically corrects discrepancies between check amounts and payment amounts when using third-party checks for vendor payments. Previously, users had to manually adjust payment amounts, leading to errors and delays. This change ensures accurate payment processing and eliminates the need for manual intervention.
Original PR description
Current behavior: when using third-party checks to create vendor payments, withholding amounts are creating a difference between the checks amount and the payment amount, resulting in a warning and requiring manual adjustment of the payment amount until the amount minus withholdings matches checks amount. Solution: adding an automated adjustment algorithm to the wizard. task-4257629 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#219922
This update fixes an issue where the quantity of products scanned via GS1 barcodes wasn't correctly reflected in manufacturing orders. Previously, the system only added one unit regardless of the barcode's specified quantity. Now, the system accurately uses the barcode's quantity to update the finished product's output, ensuring consistency and accurate tracking of manufactured goods.
Original PR description
Description of the issue/feature this PR addresses: The quantity of GS1 barcodes was not taken into account when scanning the final product of a manufacturing order. More details of this issue can be found in https://www.odoo.com/odoo/project.task/4817418 Current behavior before PR: When scanning a GS1 barcode with a quantity defined (e.g. 0120250524135700310210000010LOT887766 ) as the final product of a manufacturing order, the quantity is not taken into account in the call to produceQty(), so the line will have a qty_done of 0 regardless of the quantity specified in the barcode Desired behavior after PR is merged: The qty_done of the final product line should be the one specified in the barcode, in order to make the behaviour consistent with other usages of GS1 barcodes. Forward-Port-Of: odoo/enterprise#104240 Forward-Port-Of: odoo/enterprise#95174
This update fixes a restriction that prevented non-administrator users from updating GI CFDI sequences. Previously, sequence updates required elevated privileges, limiting functionality. Now, all users can update these sequences, streamlining the process and improving efficiency.
Original PR description
In odoo/enterprise#102500, support was added for custom GI CFDI sequences at branch level. However, the sequence consumption fails for non-admin users due to missing write access on ir.sequence, so sudo() is required when updating number_next. Forward-Port-Of: odoo/enterprise#104242
This update resolves an issue where FrontDesk hosts with limited access were unable to check out visitors via email. The fix allows hosts to complete the checkout process by running actions with elevated permissions, ensuring a smooth visitor experience. This improves usability for FrontDesk staff.
Original PR description
Steps to reproduce: * Create a visitor record with a host who has only FrontDesk user access. * Ensure Notify with Email is enabled on the station. * Click Check Out Visitor from the received email → access error appears. Issue: * Hosts with only FrontDesk user access received an access error when clicking the “Check Out Visitor” button from the email notification. * They were unable to complete the visitor checkout process. Fix: * Run the checkout action with sudo() so the host can successfully check out the visitor from the email link. Impact: * Hosts can now check out visitors without encountering permission errors. task-5373026 Forward-Port-Of: odoo/enterprise#101179
This update streamlines the process for inviting users to channels. The redundant 'invite people' button has been removed from channel types with member lists, consolidating the invitation option within the member list panel. This improves user experience and reduces visual clutter.
Original PR description
*=im_livechat Previously, channels with `memberList` had two ways to invite new users — one through the header action button and another via the member list panel. This caused redundancy since both performed the same action. This commit removes the header invite button for channel types that already have a member list and keeps only the invite option inside the member list panel. The behavior for chat-type channels remains unchanged. In addition, the invite button in the member list panel now opens a proper dialog instead of a popover. Invite buttons in other areas, such as the sidebar and chat window actions, remains unchanged for ease of access enterprise: https://github.com/odoo/enterprise/pull/98457 Task-5406953
This update streamlines the process of inviting new users to WhatsApp channels by utilizing the existing member list panel's invitation button. This change, stemming from a previous update, simplifies user onboarding and removes a redundant action from the channel interface. It ensures a more consistent and efficient user experience.
Original PR description
After https://github.com/odoo/odoo/pull/233389, we rely on the member list panel's invite button to invite any new user and remove the dedicated invite action form the thread header action list for all channel type that have member list. This commit adapts the failing test for the same. community: https://github.com/odoo/odoo/pull/233389 Task-5406953
This update resolves an issue where tests related to stock valuation in manufacturing were disabled. The fix ensures accurate calculations for product costs, particularly in subcontracting scenarios, by re-enabling the relevant tests. This improves the reliability of our manufacturing accounting processes.
Original PR description
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#234589
This update resolves several issues impacting the accuracy of account reports related to MRP (Material Requirements Planning) within the Odoo Enterprise system. The changes focus on improving the reliability of tests for key modules like 'mrp_workorder_hr_account', ensuring accurate financial reporting and data integrity. This resolves a previously identified bug.
Original PR description
Forward-Port-Of: odoo/enterprise#98924
This update resolves a technical problem preventing order data from being correctly saved in the Odoo POS system for Sweden. The fix involves renaming related fields in the user interface to ensure data synchronization with the database. This ensures accurate order tracking and reporting.
Original PR description
In commit 807420a, the `pos.order` fields in `pos_l10n_se` were renamed to add `sweden_` at the start. However, these fields were not renamed in the JS code. The result is that the fields were not being saved to the DB. This commit fixes the issue by renaming the fields in the frontend. It also adds some fixes to ensure compatibility with the newest IoT box image. opw-5253585 Forward-Port-Of: odoo/enterprise#104321 Forward-Port-Of: odoo/enterprise#104180
This update ensures that website order taxes are recalculated accurately when a customer's address is changed. Previously, this process was limited, but this fix introduces a flexible mechanism to recompute taxes for draft website orders, preventing incorrect tax calculations. This improves the accuracy of pricing and order totals.
Original PR description
Followup of 290d77cde41295b28aa522025136b48f74abcfc5.
When updating a partner address that may impact the fiscal position, we will recompute the fiscal position (and taxes) for draft website orders.
But other modules may also need to recompute other records, so avoid repeating the recomputing, this commit introduces a hook to allow extending the subset of records for which we need to recompute the fiscal position and taxes.
As the extended domain may contain non-draft records, ensure we only recompute prices for draft orders.
opw-5365258
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#243047This update fixes an issue where subscription and invoice calculations were incorrect after a partner's address was updated. The change ensures that fiscal positions and taxes are automatically recomputed when subscriptions are running or churned subscriptions are reopened, guaranteeing accurate tax and amount reporting.
Original PR description
When updating a partner address that may impact the fiscal position, we need to ensure the fiscal position (and taxes) are also updated on running subscription or when reopening a churned subscription. Otherwise the subscription and generate invoices won't have the correct taxes and amount. opw-5365258 Forward-Port-Of: odoo/enterprise#103802
This update hides the 'suggest next documents' tab within the signing feature from users who are not logged in. This ensures that sensitive document suggestions are only visible to authorized users, improving data security and privacy. The change was implemented as a fix to a previous vulnerability.
Original PR description
This commit makes the suggestion tab of signing next documents hidden to public users, as they should be logged in to be able to see the next documents to be signed. task-5487349 Forward-Port-Of: odoo/enterprise#104287
This update corrects an issue where half-day leave requests were incorrectly calculated as full days. The fix removes a problematic filter, ensuring that half-day leave requests with 'sandwich leave' enabled display the correct duration of 2 days instead of 4. This improves the accuracy of leave tracking for Indian companies.
Original PR description
**Steps:** 1. Install the `l10n_in_hr_holidays` module and create an Indian company 2. Create a time-off type that has `half-days` as the request unit and set "sandwich leave" to true 3. Create a leave request from December 12 to December 15, 2025 it should display a duration of 2 days instead of 4 **Cause:** The filter was removing leaves that had `half-day` set as the request unit **Fix:** The half-day filter is removed. In `_l10n_in_is_full_day_request` method we will check for actual half-day leave If the `request_date_from_period` and `request_date_to_period` are the same, then it is not considered a full-day leave, and it will not be calculated as a sandwich leave. Task-5427415 Forward-Port-Of: odoo/odoo#240542
This update resolves problems with how documents are linked to journal entries, ensuring invoices and vendor bills correctly move to the intended accounting folders and receive the correct tags. It corrects a previous issue where actions were executed in the wrong order, leading to documents being misfiled.
Original PR description
This PR addresses three related issues in the documents_account module regarding document folder synchronization and the execution order of server actions. **Fix 1:** Sync on Account Move Creation.…
This PR addresses three related issues in the documents_account module regarding document folder synchronization and the execution order of server actions. **Fix 1:** Sync on Account Move Creation. Fixed a regression (introduced in 2333367) where documents failed to move to the correct Journal folder and apply tags when creating a new account move. Also added a small refactor to flatten the structure. The tests added in Fix 3 would catch this regression in the future. **Fix 2:** Sync on Miscellaneous Entry Creation Previously, creating a Miscellaneous Entry (move_type='entry') from an existing document failed to move the document from its original location (e.g., "Finance") to the correct accounting folder. The existing sync logic explicitly skipped entries to avoid issues with multi-attachement invoices. **Fix 3:** Execution Order of Multi-Actions. Previously, multi-step server actions (e.g., 'Create Vendor Bill') executed child actions alphabetically. This caused the manual "Move to Taxes" action to execute after the record creation sync, effectively overriding the correct journal folder placement and moving the document to a generic folder (e.g. 'Taxes'). Changes: - Enforced a specific execution order: The document is now moved before the accounting record is created. This ensures the final automatic sync prevails. - Additionally, the action is temporarily embedded (pinned) on the intermediate folder during execution to allow the subsequent record creation to proceed even after the document has been moved to a new folder (which would otherwise fail consistency checks). Changes: - Extended `ir.attachment.write` to detect when a document is linked to an account.move of type 'entry'. - Triggers `_update_or_create_document` immediately upon linking to ensure tags and folders are synchronized. Task-5452729 Task-5452880 Forward-Port-Of: odoo/enterprise#103096
This update fixes a bug where email templates with images would sometimes duplicate themselves when saved. The change ensures all images load completely before processing, preventing errors and the duplication of content. This improves the stability and reliability of email template creation and management.
Original PR description
Problem: In Email templates, having an email with an image using `t-att-src` (Qweb) on save will duplicate the template. Cause: Images without a `src` attribute (or empty src) make `waitUntilImagesLoaded` fail immediately if the image loading promise rejects. Because the errors were not caught, the inline conversion process was interrupted and duplicating content. Solution: Use `Promise.allSettled` instead of `Promise.all` to ensure the system waits for all images to finish loading regardless of success or failure. Additionally, filter the query selector to strictly select images with a non-empty `src` attribute (`img[src]:not([src=""])`) to avoid processing invalid or dynamic Qweb images. Steps to reproduce: - Open An email template with Qweb image. - Do a change and save. - Observe the content is duplicated. opw-5489040 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243725
This update resolves a technical issue within the Odoo Enterprise HR payroll module that could cause errors when creating rule parameters with future dates. The fix ensures that computed fields are correctly initialized, preventing a traceback and guaranteeing accurate payroll calculations. This improves the stability and reliability of the payroll process.
Original PR description
Steps to reproduce: -------------------------------- 1. Install `hr_payroll` module without demo 2. Go to Payroll > Configuration > Rule Parameters 3. Create a new rule parameter with code 4. In…
Steps to reproduce:
--------------------------------
1. Install `hr_payroll` module without demo
2. Go to Payroll > Configuration > Rule Parameters
3. Create a new rule parameter with code
4. In history page select the date in future
Observation:
--------------------------------
Traceback occurs:
```
File '/home/odoo/odoo/community/odoo/orm/fields.py', line 1456, in __get__
raise ValueError(f'Compute method failed to assign {missing_recs}.{self.name}')
ValueError: Compute method failed to assign hr.rule.parameter(2,).current_value_one_line
```
Issue:
--------------------------------
https://github.com/odoo/enterprise/blob/bbf53fbfc19e4c422cfefabd4689fc0f5156d359/hr_payroll/models/hr_rule_parameter.py#L88-L106 The compute method assigns values only inside conditional blocks. When both conditions fail, the method exits without assigning any value to the computed fields, causing a compute error
Solution:
--------------------------------
Initialize the computed fields with `False` before the conditional logic. If the second condition is met, the correct value is then assigned. This prevents the traceback and ensures proper field computation.
opw-5438500
Forward-Port-Of: odoo/enterprise#104346
Forward-Port-Of: odoo/enterprise#102924This update resolves an issue preventing credit notes created with DIAN support documents from successfully sending. The problem stemmed from an incorrect namespace being used, causing errors during the document generation process. This fix ensures credit notes with DIAN support documents can be properly sent, improving compliance and data accuracy.
Original PR description
**PROBLEM** When trying to create a credit notes using a journal with support documents, there is a lot of errors when sending the dian documents. **STEP TO REPRODUCE** 1. setup DIAN (knowledge page https://www.odoo.com/odoo/knowledge/5/knowledge/23114). 2. create a vendor bill, and then create a credit note with the DIAN support document journal. 3. Confirm and click on send DIAN documents. **CAUSE** `_get_document_nsmap()` uses the wrong namespace for credit notes. opw-5378540 Forward-Port-Of: odoo/enterprise#103821
This update fixes an issue where translated text within views was being incorrectly escaped, preventing it from displaying properly. The change ensures that translated strings are rendered as HTML, allowing for accurate and consistent display of localized content. This improves the user experience by correctly showing translated text in various Odoo views.
Original PR description
Following the semantic change in QWeb `t-call`, node attributes are now treated as function arguments. Previously, these were defined via `t-set`, which produced QwebContent capable of holding…
Following the semantic change in QWeb `t-call`, node attributes are now treated as function arguments. Previously, these were defined via `t-set`, which produced QwebContent capable of holding XML/HTML.
When `edit_translations` is active, translated strings are wrapped in `<span>` tags containing translation metadata. To maintain backward compatibility and allow in-place translation, values from `.translate` attributes are now explicitly marked as Markup safe elements. This ensures that the translation wrappers are correctly rendered as HTML rather than escaped text.
Exemple:
```xml
<t t-call="payment.submit_button">
<button><t t-out="submit_button_label"/></button>
</t>
<t t-name="payment.mytemplate">
<div class="modal-body">
<div class="float-end mt-2" t-att-data-provider-id="provider_sudo.id">
<t t-call="payment.submit_button" submit_button_label.translate="Pay"/>
</div>
</div>
</t>
```
When reading the views, `submit_button_label` value must be translated. We We want the button to be rendered with the translated value and not to display the escaped char like "<".
see: https://github.com/odoo-dev/odoo/commit/eb6e88a25050fff2bd09317739dd51ba451450df
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#243473This update resolves a display problem in the General Ledger report when using analytic accounting. Previously, the report showed incorrect information and linked to the wrong journal entries. The fix ensures the General Ledger accurately reflects analytic account groupings, providing correct data and navigation.
Original PR description
Issue: Inconsistent use of line ID in the general ledger between account_move_line.id and account_analytic_line.id Step to reproduce: - Activate analytic accounting - Go to Accounting Report ->…
Issue: Inconsistent use of line ID in the general ledger between account_move_line.id and account_analytic_line.id Step to reproduce: - Activate analytic accounting - Go to Accounting Report -> General Ledger -> Options - Activate "Analytic Group By" - Create an invoice - add a line with an analytic account - Confirm the Invoice - Duplicate the invoice - Confirm the second invoice - Go to the General Ledger - Group By the analytic account you used Current Behavior: General Ledger display 2 lines per journal entry being part of the analytic distribution used for the group by. The first line displays the part related to the analytic group by, while the second line display infos for global general ledger. Clicking on the dots of the first line -> "View Journal Entry" send you to an unrelated entry. Expected behavior: - "View Journal Entry" should send to the right entry Proposed Solution: To proceed to the group_by, `_prepare_lines_for_analytic_groupby` create a temporary SQL table. This table uses the account_analytic_line.id as if it was the account_move_line.id. This commit fixes this and goes back to account_move_line.id. However, lines are merged into only one single line. opw-5267981 Forward-Port-Of: odoo/enterprise#104082 Forward-Port-Of: odoo/enterprise#103169
This pull request fixes a reporting issue related to Bebat, a Belgian organization recycling used batteries. It ensures that recycling tax charges are correctly identified as 'Special Agreement' (64) or 'Battery Collection and Recycling' (CAV) instead of the previous 'New Outlet Discount' (66) classification, aligning with regulatory requirements.
Original PR description
[FIX] account_edi_ubl_cii: EPD allowance/charge code should be 64, not 66 64 stands for "Special agreement" 66 stands for "New outlet discount" opw-5478324 [FIX] account_edi_ubl_cii: Bebat allowanceChargeReasonCode should be CAV Bebat is a non-profit organization in Belgium that collects, sorts, and recycles used batteries. Currently, whatever the recycling tax applied, we report is as AEO for "Collection and recycling - The service of collection and recycling products." However, since Bebat is about recycling batteries, we have to use CAV instead for "Battery collection and recycling - The service of collecting and recycling batteries." opw-5474752 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243064
This update fixes an error in the Mexican payroll module that caused incorrect period end calculations when creating pay runs with schedules like '10 Days' or 'Bi-weekly'. The code was updated to align with the standard payroll method, ensuring accurate period determination for Mexican companies.
Original PR description
Bug: When we create a new pay run for a mexican company and we select the schedule "10 Days", "14 Days", "Bi-weekly" or "Bi-monthly", the end of the period is computed incorrectly. Cause: The standard method changed but it wasn't updated in the mexican payroll module. Fix: Change the signature of the method to match the one in hr_payroll. Task: 5421825 Forward-Port-Of: odoo/enterprise#104039 Forward-Port-Of: odoo/enterprise#102326
This update prevents public users from making changes to department configurations within the Employees app. Previously, they had unintended write access, which has now been corrected. This ensures data integrity and prevents unauthorized modifications to department settings.
Original PR description
**Steps to reproduce:** - Install Employees app - Login as public user - Go to Employees menu - Press on any employee to open its form view - Press on the department field - Try to edit the department configuration **Issue:** Public users can edit all the fields on the department configuration, except the Department's manager. This is should not be the case. **Solution:** Remove write access on department for public users. Task: 5384463 Forward-Port-Of: odoo/odoo#239027
This update resolves an issue where rental prices weren't being calculated correctly due to an error in how the system processed certain data. The fix ensures that rental prices are accurately computed, improving the reliability of rental agreements within the system. This impacts the accurate reporting and pricing of rental products.
Original PR description
Kwargs were wrongly extracted in an override, leading to a traceback because the same arguments were provided twice to the super call.
This update ensures that rating cards are only shown in the portal chatter for modules that specifically request them. Previously, rating cards were displayed even when not intended, leading to a cluttered user experience. This change improves portal clarity and focuses the rating feature on its core use cases.
Original PR description
*: test_mail_full Modules using portal rating can set an `data-display_rating` attribute when calling the portal chatter template to indicate whether they want the rating feature displayed. Currently, only two modules have this attribute set to true: ecommerce and elearning. For other modules that don't set this attribute, even if there is a rating, such as when rating a ticket in the helpdesk module, we don't want the rating card feature to be shown in portal chatter. This change ensures that the feature is only available if the module requests it. task-5347848 Forward-Port-Of: odoo/odoo#243495 Forward-Port-Of: odoo/odoo#243255
This update fixes a display issue in the restaurant order preparation screen (PDIS) where the first course's timer incorrectly showed 0 until the second course was initiated. Now, each course accurately reflects its preparation time when it's added to the order, improving the customer experience and order accuracy.
Original PR description
Before this commit: -- - In the preparation display (PDIS), the first course shows a preparation time of 0 untill the second course is fired. - After course 2 fired, course 1 and course 2 have same preparation time value. After this commit: -- - Each course shows its correct preparation time when fired. task-5421616 Forward-Port-Of: odoo/odoo#243413 Forward-Port-Of: odoo/odoo#241251
This update fixes an issue where the 'Code' hint wasn't visible when a cursor was placed in an empty code block after syntax highlighting was implemented. The fix utilizes a native placeholder attribute in the textarea, ensuring the hint is consistently displayed for code blocks, improving the user experience within the HTML editor.
Original PR description
#### Description of the issue this PR addresses: - After syntax highlighting was introduced, placing the cursor inside an empty code block no longer displayed the 'Code' hint. - The hint logic gets the syntax-highlighing element instead of the `<pre>` element, and the `<pre>` is the child of syntax-highlighing node, and that is marked as data-oe-protected='true', so the`<pre>` is treated as a protected node and is not eligible for hint rendering. #### Desired behavior after PR is merged: - For code blocks, use the native placeholder attribute on the <textarea> and control its visibility based on focus. task-5473682 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243042
This update resolves a bug where manually changed currency rates on invoices weren't updating correctly, leading to lost data. The fix now only recalculates rates and lines if the user hasn't modified them, ensuring accurate currency calculations for invoices with different dates than their creation.
Original PR description
in case the user would enter manually a different rate than the default one, but does not fill the invoice date; odoo was setting today as the invoice date, which was changing the rate and recomputing all the lines... Effectively losing everything the user just encoded. So now, we only recompute the rate and the lines if the user didn't change it. Fix: https://github.com/odoo/odoo/pull/226124/changes/1b48d141d7260a262075555c4ab9cedc691d3551 Issue with Fix: Invoices posted on dates different from their creation date do not update their currency rates, even though they should. Comparing `invoice_currency_rate` to the expected rate at creation is a better guess. task-5477481 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243832 Forward-Port-Of: odoo/odoo#242800
This update resolves an issue where group channels (DMs with fewer than 3 members) were displaying incorrect status information, such as an 'IM status' or 'back on' banner. By removing a specific calculation, the system now accurately reflects the channel type, leading to a more reliable and consistent user experience for group conversations. This ensures notifications and channel displays are correct.
Original PR description
Before this commit, the "correspondent" property of Thread would be computed for channels of type group (group DMs) having less than 3 members. This would lead to various confusing behaviours, including: 1. The "back on" banner being shown. 2. The chat bubble showing an IM status. 3. The notification item not showing the message author's name. This commit fixes the issues by not computing `correspondent` for channels of type group. task-5462395 Forward-Port-Of: odoo/odoo#243628 Forward-Port-Of: odoo/odoo#242058
This change prevents the 'Update Prices' button from appearing on sales orders when a pricelist hasn't been set up. Previously, the button was incorrectly displayed, potentially confusing users. This ensures a cleaner user experience and avoids unnecessary actions when pricelists aren't in use.
Original PR description
**Steps to produce:** - Install the `Sales` module. - Enable `Pricelists` in settings and set the `default quotation template`. - Create a new Sales Order. **Issue:** - The `Update Prices` button is…
**Steps to produce:** - Install the `Sales` module. - Enable `Pricelists` in settings and set the `default quotation template`. - Create a new Sales Order. **Issue:** - The `Update Prices` button is visible even when no pricelist is set on the sales order. **Root cause:** - In the onchange logic (see [1]), show_update_pricelist is set to True based solely on the presence of order lines, without checking whether a pricelist is defined. **Solution**: - Update the condition so that button is shown only when sale order line is present and the current pricelist value is not the previous one. [1]: https://github.com/odoo/odoo/blob/849ec71acbaea0061fd4b13888a486e4aebb6463/addons/sale/models/sale_order.py#L801-L803 Before: <img width="1215" height="466" alt="image" src="https://github.com/user-attachments/assets/f29b1ccf-eec8-4114-b4c9-a8083947ad28" /> After: <img width="1207" height="428" alt="image" src="https://github.com/user-attachments/assets/e358b633-d11b-413d-94c4-3837c430eac4" /> opw-5414897 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243410 Forward-Port-Of: odoo/odoo#241812
This update resolves a technical error that prevented users from creating and saving bank statements within the Accounting module. The issue stemmed from a problem accessing data within the system, now corrected by passing data as 'props'. This ensures the bank statement creation process functions correctly.
Original PR description
We get an owl error: `TypeError: Cannot read properties of undefined (reading 'root').` The code tries to read data from this.env.model, but it is undefined. Steps To Reproduce: 1. Install `account_accountant` 2. Go to Accounting Dashboard > Bank > `...` > Transactions 3. Open in the list view 4. Select any number of transactions 5. Type something in the statement field of one of the rows 6. Press Create and Edit to create a new Statement 8. Save the statement Ticket [link](https://www.odoo.com/odoo/project.task/5352277) opw-5352277 Forward-Port-Of: odoo/enterprise#104072 Forward-Port-Of: odoo/enterprise#101232
This fix ensures that discounts applied through pricelists are correctly calculated even when a negative quantity is entered in the Point of Sale system. Previously, the system didn't apply the discount rule when a negative quantity was selected. This change corrects a discrepancy between the backend and frontend pricing logic.
Original PR description
Steps to reproduce: ------------------- 1. Create a pricelist with a rule of 50% discount on all product, and a `min_quantity` of ZERO. 2. In PoS select this pricelist, and add a product originally priced at 10; the pricelist is well applied and the new price is 5. 3. Now, from the numpad, click change the quantity from 1 to -1 (click on the "+/-" button. Observation: The pricelist rule is not applied anymore. The price is -10 and not -5. Why it's an issue ----------------- `getPrice` on frontend is a port of `_get_product_price` on product.pricelist. There, in `_is_applicable_for`, we apply the price rule if it's `min_quantity` is 0, regardless of the bought quantity. So there's a mismatch between applying the rule on backend and frontend. This worked well on 18.0, before 43bfda63faeb4713dbeb1d11457673aafaa544b4. opw-5431651 Forward-Port-Of: odoo/odoo#241608
This update fixes an issue where changes to the website footer (specifically structural edits like changing links to buttons) were lost after upgrading the 'Website' app. The fix ensures that edits made in one language are correctly applied across all languages, improving the reliability of website customizations. This prevents users from needing to re-apply changes after updates.
Original PR description
In commit 03a85b13b2c46ef7174123d902e95d5103031c6c, delayed translations were restored. Delayed translations of a view were lost on upgrade of the module that contains the corresponding generic view.…
In commit 03a85b13b2c46ef7174123d902e95d5103031c6c, delayed translations were restored. Delayed translations of a view were lost on upgrade of the module that contains the corresponding generic view. This happened because the update of the view did not take into account the possible delayed translations when updating it and the translations in specific views. This commit updates (and uses as source) the current versions, instead of the delayed ones. Steps to reproduce: - Install a second language for the website - Set the default language for the website to the second language - Edit footer by changing structure not just text (like changing a link to have a button appearance) - Upgrade the "Website" app - Bug: footer lost the last edit Steps to reproduce: - Install a second language for the website - Edit footer by changing structure not just text (like changing a link to have a button appearance) - (Observe that the change is not in the website in the second language) - Upgrade the "Website" app - Bug: the change is now in the website in the second language task-5248173 Fixes #233723 Forward-Port-Of: odoo/odoo#241677
A technical issue with WebKit was preventing users from correctly scanning barcodes on iOS devices. This resulted in a white square obscuring the scanning area. This update resolves the problem by addressing the underlying WebKit bug, ensuring accurate barcode scanning functionality for iOS users.
Original PR description
Issue ----- There is an issue in WebKit with mix-blend-mode https://bugs.webkit.org/show_bug.cgi?id=286619 Because of this issue, in barcode, the user gets a solid white square over the scanning zone, so they don't see the barcode being scanned. ----- Ticket: opw-5386846 Forward-Port-Of: odoo/odoo#243486
This update optimizes how Odoo handles web sockets, particularly when dealing with a large number of connected clients. By tweaking the delay in acquiring web socket cursors, the system now recovers more effectively from connection bottlenecks, preventing disconnections and maintaining performance under heavy load. This ensures a smoother experience for users.
Original PR description
Benchmarking with 4k connected clients, 1 message per second. | | Message dispatching | Cursor analysis | |-- |-- | -- | | Before|<img width="600" alt="image" src="https://github.com/user-attachments/assets/f02e7efc-4611-4356-8bef-386ff2b0a7da" />|<img width="600" alt="2_current_implementation__cursor_analysis" src="https://github.com/user-attachments/assets/04dce96e-74a6-4f1b-9918-a6c61913e7c4" />| |After|<img width="600" alt="image" src="https://github.com/user-attachments/assets/a9463484-7f69-4fcb-a248-5692893a8893" />|<img width="600" height="997" alt="8_tweak_delay_both_sleep__cursor_analysis" src="https://github.com/user-attachments/assets/34a2c233-5c36-4597-a55b-cfb89a41efcf" />| Forward-Port-Of: odoo/odoo#241788 Forward-Port-Of: odoo/odoo#241330
This update ensures that transfer links remain accurate after manufacturing merged production orders. Previously, the system incorrectly assigned default warehouse locations, causing issues with complex multi-location workflows. This fix guarantees the correct location is used for transfers, improving the reliability of manufacturing processes.
Original PR description
Situation ----- When applying a push rule after manufacturing a merged MO, there is an odd case where the link between the merged MO's transfer and the demand move breaks in…
Situation ----- When applying a push rule after manufacturing a merged MO, there is an odd case where the link between the merged MO's transfer and the demand move breaks in https://github.com/odoo/odoo/blob/182a387d0ec6ad28d7d052d7100b2184372514be/addons/stock/models/stock_move.py#L1054 because of the `m.location_id == move.location_final_id` part being false in https://github.com/odoo/odoo/blob/182a387d0ec6ad28d7d052d7100b2184372514be/addons/stock/models/stock_move.py#L1090-L1097 This is because, during the merge, `location_final_id` is not propagated to the new MO https://github.com/odoo/odoo/blob/5f8336c7d8ab891103a3035a9ebb5242cfa46ce6/addons/mrp/models/mrp_production.py#L2416-L2424 so when the new MO's `move_finished_id` gets computed https://github.com/odoo/odoo/blob/5f8336c7d8ab891103a3035a9ebb5242cfa46ce6/addons/mrp/models/mrp_production.py#L822 it gets the MO's `location_final_id` https://github.com/odoo/odoo/blob/5f8336c7d8ab891103a3035a9ebb5242cfa46ce6/addons/mrp/models/mrp_production.py#L1202 which is false. This leads to to the move getting the warehouse's default stock location thanks to https://github.com/odoo/odoo/blob/182a387d0ec6ad28d7d052d7100b2184372514be/addons/mrp/models/stock_move.py#L456-L457 This is problematic for complex use cases with multi-locations and custom routes. It should be safe to propagate the `location_final_id` of the merged MOs if they all share the same one. Use case example ----- <details> <summary>Full use case</summary> - Enable multi-step routes - Create location "WH/Stock/L1" - Create location "WH/Stock/L2" - Create Operation Type "MO child" - Type of Operation: Manufacturing - Sequence Prefix: MOCHILD - Source Location: L1 - Destination Location: L2 - Create Operation Type "Push Transfer" - Type of Operation: Internal Transfer - Sequence Prefix: L2L1 - Source Location: L2 - Destination Location: L1 - Create Route "MO child" - Create Rule "Manufacture" - Action: Manufacture - Operation Type: MO child - Source Location: False - Destination Location: Stock - Create Route "2-step" - Warehouse: Main WH - Create Rule "L1 -> Virtual/Production" - Action: Pull from - Operation Type: MO child - Source Location: L1 - Destination Location: Virtual/Production - Create Rule "Push: L2 -> L1" - Action: Push To - Operation Type: Push Transfer - Source Location: L2 - Destination Location: L1 - Unarchive MTO - Edit MTO route - Create Rule "L1 -> Virtual/production (MTO)" - Action: Pull - Operation Type: "My Company: Manufacturing" - Source Location: L1 - Destination Location: Virtual/Production - Supply Method: Trigger another rule - Create product "Main product" - Create product "Child product" - Routes: "MO child" & MTO - Create product "Material" (consumable) - Create BOM - Product: "Main product" - Component: "Child product" - Create BOM - Product: "Child product" - Component: "Material" - Create MO for "Main product" - Misc/Component Location set to L1 - Duplicate the MO - Merge child MOs & produce - Validate merged MO transfer to L1 - Go back to one of the "Main product" MO > Component quantity is 0 </details> ----- Ticket: opw-5144196 Forward-Port-Of: odoo/odoo#242801 Forward-Port-Of: odoo/odoo#240695
This update ensures that product attributes are correctly displayed on refund orders and receipts. Previously, when a customer refunded an order with variants, the attributes were lost during the refund process. This fix correctly transfers the attributes from the original order to the new refund order, improving the accuracy of refund records.
Original PR description
**Steps to reproduce:** - Make an order with a product that has variants and chose whatever in the popup - Pay for that order, then refund it - The attribute is not shown on the orderline anymore - The attribute is not shown on the receipt either **Why the fix:** When making a refund, we are actually making a new order, so we need to move the data from the old order to the new refund order. During this transit, the *attribute_value_ids* was forgotten on the moving lines, so the attributes were lost. We now give the old attributes to the new line. opw-5393332 Forward-Port-Of: odoo/odoo#243300 Forward-Port-Of: odoo/odoo#240602
This update resolves an issue where saving accounting reports with incorrect formulas would generate an error. The fix ensures the system handles invalid 'Prefix of Account Codes' settings gracefully, preventing report failures and improving data reliability. This change impacts the accounting report generation process.
Original PR description
Saving an accounting report with an invalid ``Prefix of Account Codes`` formula will raise a traceback. Steps to reproduce the error: - Install ``accountant`` module - Go to Accounting >…
Saving an accounting report with an invalid ``Prefix of Account Codes`` formula will raise a traceback. Steps to reproduce the error: - Install ``accountant`` module - Go to Accounting > Configuration > Accounting Reports > Open any report > Add a line > Add name > Add a line > Add a Expression > Computation Engine: Prefix of Account Codes > Formula: test( > Save the report Traceback: ```py TypeError: 'NoneType' object is not subscriptable ``` https://github.com/odoo/odoo/blob/1ac7834a9b9d07760700f6d7c73dfe270a247752/addons/account/models/account_report.py#L661-L662 Here, if the token does not match the regex, ``token_match`` will be ``None``, The code then accesses ``token_match['prefix']`` which leads to the above traceback. https://github.com/odoo/odoo/blob/312964fdf68609dbd0fc1bb3be609b50e171b0c3/odoo/tools/translate.py#L556 Here, no translation language is detected by ``_get_lang``. To resolve this, ``self.env._()`` is added instead of ``_()`` at below line. https://github.com/odoo/odoo/blob/312964fdf68609dbd0fc1bb3be609b50e171b0c3/addons/account/models/account_report.py#L646-L648 sentry-7175078855 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243283
This update resolves an issue where failed IoT driver actions were incorrectly recorded, preventing them from being re-executed. Now, actions are only registered upon successful completion, enhancing the reliability and efficiency of IoT driver operations. This change improves the overall stability of the system.
Original PR description
We currently reject an action if it has the same id of a previous one. If the action failed, we still registered it, making it impossible to be executed again. We now only register if the action succeeds. Forward-Port-Of: odoo/odoo#243913 Forward-Port-Of: odoo/odoo#243247
This update resolves an issue where clicking 'Back' in the self-order POS system sometimes caused incorrect product additions to the cart. The fix clarifies the trigger for product clicks, preventing confusion and ensuring accurate cart updates. This improves the overall reliability of the self-order experience.
Original PR description
Before this commit, trigger to click on a product in the product list was the same trigger to click on a product in a cart list ... With the following scenario, step CartPage.clickBack() can take few…
Before this commit, trigger to click on a product in the product list was the same trigger to click on a product in a cart list ...
With the following scenario, step CartPage.clickBack() can take few times to show the back screen, but as the trigger is the same for clickProduct on a product list screen than a cart screen, the last step clik on "o_self_product_box" ... but in the cart (and not in the product list)
ProductPage.clickProduct("Coca-Cola"), => OK
ProductPage.clickProduct("Coca-Cola"), => OK
Utils.clickBtn("Checkout"), => OK
CartPage.checkProduct("Coca-Cola", "5.06", "2"), => OK CartPage.clickBack(), => OK
ProductPage.clickProduct("Coca-Cola"), => NOK
To fix it, it is enought to just be more precise on the trigger to avoid confusions.
This fix fixes probably a pair of tours.
error-runbot-id~227669
(and probably others)
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#243749This update addresses a technical issue within the Odoo spreadsheet module where pivot tables would generate tracebacks when encountering fields that were no longer present due to data changes or module removals. The fix ensures the spreadsheet functionality remains stable and reliable, even with evolving data structures. This prevents disruptions to users generating reports.
Original PR description
Task: 5085724 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#228166
This update resolves a technical issue that caused a traceback error when creating pivot tables in the spreadsheet reports. The fix ensures that pivot tables function correctly, even when certain data dimensions are missing, improving the reliability of reporting. This enhances the usability of the enterprise spreadsheet functionality.
Original PR description
Task: 5085724 Forward-Port-Of: odoo/enterprise#103369
This update fixes an issue where follower list avatars weren't consistently displayed with the correct proportions, particularly for non-square images. The change utilizes a standard Odoo class for avatars, ensuring all images are displayed correctly and maintaining a professional appearance. This improves the visual quality of the follower list.
Original PR description
Before this commit, follower list menu had avatar that do not preserve ratio of avatars. This is noticeable for avatars that have ratio quite different from 1:1, like 3:2 or 2:3 or even less squarish. This happens because of missing `.o_object_fit_cover`, that [1] erroneously removed from REF of follower template part into its own component. This commit uses an equivalent but more official solution: `.o_avatar`, which is a classname dedicated for avatars, which has `.o_object_fit_cover` property. Task-5412078 Before / After <img width="638" height="526" alt="Screenshot 2026-01-12 at 17 23 54" src="https://github.com/user-attachments/assets/b8d3a921-52a8-48b7-a0d0-5fbfdd33a92c" /> <img width="640" height="528" alt="Screenshot 2026-01-12 at 17 23 33" src="https://github.com/user-attachments/assets/8070420c-f341-4085-bcb2-2fba060765f0" /> [1]: https://github.com/odoo/odoo/pull/200382 Forward-Port-Of: odoo/odoo#243684 Forward-Port-Of: odoo/odoo#243328
This update fixes a bug where changes to the analytic distribution widget weren't being saved correctly when the user navigated away from the field. Now, edits to the analytic distribution are automatically saved when the user clicks elsewhere, mirroring the behavior of other key fields like invoices. This ensures data consistency and a smoother user experience.
Original PR description
**Issue** When editing a line on the reco widget, close and keep change on analytic widget on unfocus **Steps to Reproduce** 1. Activate Analytic Accounting 2. Go on the Bank Reconciliation Widget 3. Edit a line 4. Change the Analytic Distribution. 5. Click elsewhere. 6. The Analytic Widget should close and keep the changes. (as it does on invoices) **Fix** Properly detect the condition for closing the widget. task-5232476 Forward-Port-Of: odoo/odoo#234398
This update fixes an issue where only the first attachment from an expense was included in the generated journal entries. The change ensures that all attachments associated with approved expenses are now correctly copied, improving accuracy and providing complete expense documentation.
Original PR description
**Steps to reproduce:** * Install **hr_expense** and **accounting** modules. * Create two or more expenses, each with **multiple attachments**. * Submit and approve the expenses. * Create the **journal entry** of all approved expenses. * Open the generated journal entry and review its attachments. **Observed behavior:** * Only the **first attachment** from each expense is present on the journal entry. * Additional attachments are missing. **Cause:** * while creating journal entry, the logic of expense iterate on `message_main_attachment_id`. * `message_main_attachment_id` stores only a **single attachment**, so only one file per expense is copied. **Fix:** * Iterate on `attachment_ids` instead of `message_main_attachment_id`. * Ensures **all attachments** from each expense are included in the generated journal entry. opw-5414834 Forward-Port-Of: odoo/odoo#243962 Forward-Port-Of: odoo/odoo#241044
This update fixes a problem with how mass mailing tests wait for the ThemeSelector to load, ensuring more reliable test results. Additionally, the commit optimizes test execution by removing unnecessary assets, reducing test run times by 10-40%.
Original PR description
The ThemeSelector rendering was optimized ([commit]) to minimize UX transition delays for the user, but that makes it a bit tricky to wait for in tests. This commit adds a function to properly wait for everything required to select a theme/favorite by clicking on it, in order to reduce non-determinism in `mass_mailing` tests. [commit]: https://github.com/odoo/odoo/commit/0f7ee1764e8b59029003c6ad7269e185b30c6b43 It also removes some assets loading during `mass_mailing` tests that are not relevant. This helps shave off 10-40% test time per test, depending on the complexity of the test. runbot-error-237513 runbot-error-237747 runbot-error-237769 runbot-error-237770 runbot-error-237772 task-5500038
2 changes
Resolved issues and error corrections
This update corrects a test within the Odoo website's barcode lookup feature. Recent changes in the main Odoo codebase now prevent products created through the website from automatically publishing if a category isn't selected. This fix ensures the website test accurately reflects this new behavior, maintaining consistent functionality.
Original PR description
Align barcodelookup website test with the community change where products created from the website are not auto-published when no category is selected. opw:5408903 SEE ALSO: Community PR:https://github.com/odoo/odoo/pull/242779 Forward-Port-Of: odoo/enterprise#103778
This update resolves a problem that caused Odoo to fail during database upgrades due to tracking computations triggered by a new tax module loading process. The fix disables tracking during the `_load` method execution, preventing errors and ensuring smooth module loading. This improves stability and prevents upgrade failures.
Original PR description
During database upgrades to v19, the overridden `_load` method in l10n_br_avatax writes `l10n_br_avatax_code` on `account.tax` records. ```py…
During database upgrades to v19, the overridden `_load` method in l10n_br_avatax writes `l10n_br_avatax_code` on `account.tax` records.
```py
/home/odoo/src/odoo/19.0/addons/l10n_br/migrations/1.1/end-migrate-update_taxes.py(8)migrate()
-> env['account.chart.template'].try_loading('br', company)
/home/odoo/src/odoo/19.0/addons/account/models/chart_template.py(170)try_loading()
-> return self._load(template_code, company, install_demo, force_create)
/home/odoo/src/enterprise/19.0/l10n_br_avatax/models/account_chart_template.py(12)_load()
-> self._l10n_br_init_avatax_code(company)
/home/odoo/src/enterprise/19.0/l10n_br_avatax/models/account_chart_template.py(324)_l10n_br_init_avatax_code()
-> tax.l10n_br_avatax_code = tax_data['l10n_br_avatax_code']
```
Because tracking was not disabled, this write triggered `mail.thread` tracking computation during module loading, leading to failures while finalizing tracking messages.
```py
File "/home/odoo/src/odoo/19.0/addons/mail/models/mail_thread.py", line 576, in _track_finalize
tracking = records.with_context(context)._message_track(fnames, initial_values)
File "/home/odoo/src/odoo/19.0/addons/mail/models/mail_thread.py", line 697, in _message_track
record._message_log(
File "/home/odoo/src/odoo/19.0/addons/account/models/account_tax.py", line 477, in _message_log
self._message_log_repartition_lines(tracked_value_id[2]['old_value_char'], tracked_value_id[2]['new_value_char'])
File "/home/odoo/src/odoo/19.0/addons/account/models/account_tax.py", line 423, in _message_log_repartition_lines
diff_keys = [key for key in old_value if old_value[key] != new_value[key]]
File "/home/odoo/src/odoo/19.0/addons/account/models/account_tax.py", line 423, in <listcomp>
diff_keys = [key for key in old_value if old_value[key] != new_value[key]]
KeyError: 'Porcentagem fatorial'
```
This occurs due to the interaction between:
- the `_load` override introduced in odoo/enterprise@eeaea338c1c6b9540a89be8003dadbe651de881e
- the new `try_loading` flow added in odoo/odoo@9d965abb992d558ea4235ef5f87a7654c6f1ceae
The resulting tracking computation crashes with a KeyError when processing repartition line diffs.
Fix: ensure `_load` runs with `tracking_disable=True`, as expected by the standard `_load` execution context, preventing tracking logic from running during module loading.
opw-5467986
upg-3753990
tbg-238011 changes
Resolved issues and error corrections
This update ensures that rating cards are only shown in the portal chatter for modules that specifically request their display. Previously, rating cards were sometimes shown even when not intended, leading to a cluttered user experience. This change improves the portal's clarity and relevance by aligning rating displays with module functionality.
Original PR description
*: test_mail_full Modules using portal rating can set an `data-display_rating` attribute when calling the portal chatter template to indicate whether they want the rating feature displayed. Currently, only two modules have this attribute set to true: ecommerce and elearning. For other modules that don't set this attribute, even if there is a rating, such as when rating a ticket in the helpdesk module, we don't want the rating card feature to be shown in portal chatter. This change ensures that the feature is only available if the module requests it. task-5347848 Forward-Port-Of: odoo/odoo#243495 Forward-Port-Of: odoo/odoo#243255
This update resolves an issue where the HTML editor was incorrectly adding tab characters to content, particularly when users selected mixed block types. The fix now ensures that tabs are only applied to contenteditable paragraph blocks (like headings and paragraphs), improving the editor's consistency and usability. This prevents unexpected indentation and ensures a smoother editing experience.
Original PR description
#### Description of the issue this PR addresses: - Tab indentation was applied to non-paragraph and non-contenteditable blocks, leading to incorrect indentation behavior when a selection contained mixed block types. #### Desired behavior after PR is merged: - Filter selected blocks to indent only contenteditable paragraph-related elements (h1–h6, p, pre, blockquote, and div.o-paragraph), while excluding blocks marked as contenteditable="false". #### Steps to Reproduce: - Open a new to-do record. - Insert: Table, Table of Content, Banners, attachment, (18.2 - Toggle List) - Select all editor content using Ctrl + A. - Press the Tab key multiple times. => Multiple editor tab characters are inserted at unintended positions. task-5452410 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241806
This update fixes an issue where products created through the website automatically appeared as published, even without a category assigned. The change removes a setting that forced publication and ensures products remain unpublished until a category is selected, aligning with the user's expected experience. This improves the consistency and usability of the website's product creation process.
Original PR description
**Description:** Products created from the website frontend were automatically published even without a category assigned, contradicting the "Unpublished" placeholder expectation. The issue had three root causes: 1. JavaScript (new_content.js) forced default_is_published: true 2. XML action context contained website_published: True 3. Both caused products to be published regardless of category **Fixed by:** - Removed default_is_published from JS product creation handler - Removed website_published from action context. **After this PR:** Now products remain unpublished until a category is assigned, matching the intended UX indicated by the placeholder text. opw-5408903 SEE ALSO: Enterprise PR:https://github.com/odoo/enterprise/pull/103778 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242779
This update ensures the website's product barcode lookup functionality correctly handles products created without a category selection. It aligns the test with a recent community change, preventing issues where newly created products weren't automatically published. This ensures a smoother user experience for customers creating products through the website.
Original PR description
Align barcodelookup website test with the community change where products created from the website are not auto-published when no category is selected. opw:5408903 SEE ALSO: Community PR:https://github.com/odoo/odoo/pull/242779 Forward-Port-Of: odoo/enterprise#103778
A technical issue with WebKit was preventing users from properly scanning barcodes on iOS devices. This resulted in a white square obscuring the scanning area. This update resolves the problem by addressing a bug in WebKit's blend-mode functionality, ensuring accurate barcode scanning.
Original PR description
Issue ----- There is an issue in WebKit with mix-blend-mode https://bugs.webkit.org/show_bug.cgi?id=286619 Because of this issue, in barcode, the user gets a solid white square over the scanning zone, so they don't see the barcode being scanned. ----- Ticket: opw-5386846 Forward-Port-Of: odoo/odoo#243486
This update resolves an issue where URLs were appearing twice in WhatsApp messages due to a formatting error in how the Odoo UI's HTML was converted to plain text. The fix prevents this duplication, ensuring users receive messages with URLs as intended. This improves the clarity and usability of WhatsApp communications.
Original PR description
Steps to reproduce: 1. Set up whatsapp integration. 2. Send a direct message containing a URL. 3. Observe that the URL appears twice in the message received in whatsapp. Issue: This issue arises within the `_send_message` method, where we are taking the Markup body that we use within the Odoo UI to have a clickable URL, like `<a href="https://example.com">https://example.com</a>`. Then, the html2plaintext function duplicates by adding the footnote for the anchor tag, which "duplicates" the URL since the text within the anchor tag is the same as the URL itself. This results in a message body that contains the URL twice, leading to confusion for the user. Solution: This commit addresses the issue by backporting the solution to this problem introduced in odoo/odoo@a152910 and using the `include_references` parameter of the `html2plaintext` function to exclude footnotes from the conversion. opw-4936400 Forward-Port-Of: odoo/enterprise#101083
This update fixes a bug that occurred when users attempted to apply a zero-amount discount in sales orders. The issue stemmed from a division-by-zero error. The fix ensures the system handles zero discounts gracefully, preventing errors and maintaining data integrity.
Original PR description
The system raises an error when the user tries to apply a fixed amount discount of 0.0. **Steps to produce:** - Install `Sales` module with demo data. - From the settings enable `discount`. - Make a sale order with product > click on Discount > click Fixed Amount and set amount as `0.0` > click on apply. **Error:** `ZeroDivisionError : float division by zero` **Cause:** - When the discount amount is set to 0.0, at [1] we attempt to compute the factor, which causes an error due to a division by zero. **Solution:** - Added a condition to check that current_base_amount_currency is not zero, and if it is, set the factor to 0.0. [1]: https://github.com/odoo/odoo/blob/10887c3081afbfd0734c6a3ac24301c94d14bc24/addons/account/models/account_tax.py#L3718-L3720 **sentry-6967181350** I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where tax names and invoice labels were displayed in English for Vietnamese users. By adding the necessary Vietnamese translations to the chart template CSV, users will now see tax information in their preferred Vietnamese language, improving the user experience and ensuring accurate reporting.
Original PR description
The `name` and `invoice_label` fields on `account.tax` are translatable fields (translate=True), but the Vietnamese chart template CSV was missing the corresponding translation columns. This caused…
The `name` and `invoice_label` fields on `account.tax` are translatable fields (translate=True), but the Vietnamese chart template CSV was missing the corresponding translation columns. This caused tax names and invoice labels to display in English even when the user's language was set to Vietnamese. By adding the `name@vi_VN` and `invoice_label@vi_VN` columns to the tax template CSV, taxes will now display with proper Vietnamese labels when the chart of accounts is installed for Vietnamese companies, improving the user experience for Vietnamese-speaking users. Technical details: - Added `name@vi_VN` and `invoice_label@vi_VN` columns to the CSV header - Added Vietnamese translations for all tax records in the template - Translations follow Vietnamese tax terminology conventions - The chart template loader automatically processes columns with `@lang` suffix and applies them as translations for translatable fields 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#241681 Forward-Port-Of: odoo/odoo#236502
This update fixes an issue where only the first attachment from an expense was included in the generated journal entry. The change ensures that all attachments associated with an expense are correctly copied, improving accuracy and providing complete financial records. This resolves a previous reporting discrepancy.
Original PR description
**Steps to reproduce:** * Install **hr_expense** and **accounting** modules. * Create two or more expenses, each with **multiple attachments**. * Submit and approve the expenses. * Create the **journal entry** of all approved expenses. * Open the generated journal entry and review its attachments. **Observed behavior:** * Only the **first attachment** from each expense is present on the journal entry. * Additional attachments are missing. **Cause:** * while creating journal entry, the logic of expense iterate on `message_main_attachment_id`. * `message_main_attachment_id` stores only a **single attachment**, so only one file per expense is copied. **Fix:** * Iterate on `attachment_ids` instead of `message_main_attachment_id`. * Ensures **all attachments** from each expense are included in the generated journal entry. opw-5414834 Forward-Port-Of: odoo/odoo#243962 Forward-Port-Of: odoo/odoo#241044
This update resolves an issue where scheduled email notifications and activity updates continued to run even after records were deleted. The fix prevents errors related to attempting to send messages to non-existent records, improving notification reliability and preventing confusing error messages for users. It ensures that deleted records don't cause disruptions in email workflows.
Original PR description
RATIONALE When a cascade delete occurs in DB, ORM methods are not called. More specifically loosely connected records using res_model / res_id pair are not removed when unlink override exists. SPECIFICATIONS Fix various use case in mail * notifications sent for scheduled messages; * failure notifications management; * activities mark as done; Task-5138556 Forward-Port-Of: odoo/odoo#243693 Forward-Port-Of: odoo/odoo#233071
This update addresses a potential issue where deleted records in Odoo could still be accessed, leading to errors. The fix ensures that related records are checked for existence before accessing data from deleted records, primarily due to how cascade deletions are handled in the database. This improves stability and prevents unexpected behavior when records are removed.
Original PR description
In order to be defensive we have to check records linked to messages, notifications or activities exist before checking related information like display_name, or even to skip them in various flows. This happens notably due to DB-level cascade deletion that does not remove side records linked through (model, res_id) pairs. It implies some additional exist queries. Task-5138556 Forward-Port-Of: odoo/enterprise#104243 Forward-Port-Of: odoo/enterprise#101185
3 changes
Resolved issues and error corrections
This update corrects a technical issue that caused tracebacks when generating the Follow-up Report. It ensures that General (MISC) accounting entries are automatically set to 'no_followup', with an exception for payments originating from Point of Sale (POS) systems. This improves report stability and accuracy.
Original PR description
* Fix traceback when opening the follow-up report and customer statement. * General(MISC) entries should be no_followup by default. Except entries coming from pos should not be excluded from follow-ups.
This update ensures the website's product barcode lookup feature correctly handles products created without a category selection. It aligns with a recent community change that prevents automatic publishing of products when a category isn't specified, improving data consistency and preventing potential issues.
Original PR description
Align barcodelookup website test with the community change where products created from the website are not auto-published when no category is selected. opw:5408903 SEE ALSO: Community PR:https://github.com/odoo/odoo/pull/242779 Forward-Port-Of: odoo/enterprise#103778
This update resolves an issue where URLs were appearing twice in WhatsApp messages due to a formatting error in how the Odoo UI's clickable links were converted to plain text. The fix prevents duplication by excluding footnotes during the conversion process, ensuring URLs are displayed correctly in received messages. This improves user clarity and avoids potential confusion.
Original PR description
Steps to reproduce: 1. Set up whatsapp integration. 2. Send a direct message containing a URL. 3. Observe that the URL appears twice in the message received in whatsapp. Issue: This issue arises within the `_send_message` method, where we are taking the Markup body that we use within the Odoo UI to have a clickable URL, like `<a href="https://example.com">https://example.com</a>`. Then, the html2plaintext function duplicates by adding the footnote for the anchor tag, which "duplicates" the URL since the text within the anchor tag is the same as the URL itself. This results in a message body that contains the URL twice, leading to confusion for the user. Solution: This commit addresses the issue by backporting the solution to this problem introduced in odoo/odoo@a152910 and using the `include_references` parameter of the `html2plaintext` function to exclude footnotes from the conversion. opw-4936400 Forward-Port-Of: odoo/enterprise#101083
13 changes
Resolved issues and error corrections
This update resolves an issue where the Ticket Screen in the POS Urban Piper module wasn't correctly loading order data. A recent Odoo update changed how order loading works, so this fix ensures the necessary order information is available before users can edit tickets, improving the user experience.
Original PR description
Since odoo/odoo#211804 change the order loading in background when opening the Tciket Screen. We need to ensure the component data is ready before modifying it in runtime. See odoo/odoo#211804
This update corrects a technical error that impacted the processing of annual leave data. The group assigned to a key feature related to annual leaves was mistakenly changed, leading to a runbot error. This fix ensures accurate tracking and reporting of employee leave balances.
Original PR description
Following a runbot error, the group on l10n_ae_annual_leaves_taken was changed from hr to the payroll group task-5498578
This update resolves an issue causing errors when sending DIAN documents for credit notes created with specific journals. The problem stemmed from a misconfigured namespace, preventing proper document generation. This fix ensures credit notes with DIAN support documents can be successfully sent, improving data accuracy and compliance.
Original PR description
**PROBLEM** When trying to create a credit notes using a journal with support documents, there is a lot of errors when sending the dian documents. **STEP TO REPRODUCE** 1. setup DIAN (knowledge page https://www.odoo.com/odoo/knowledge/5/knowledge/23114). 2. create a vendor bill, and then create a credit note with the DIAN support document journal. 3. Confirm and click on send DIAN documents. **CAUSE** `_get_document_nsmap()` uses the wrong namespace for credit notes. opw-5378540 Forward-Port-Of: odoo/enterprise#103821
This update fixes an issue where subscription tax calculations were incorrect after a partner's address was changed. The update ensures that fiscal positions and taxes are automatically recomputed when subscriptions are updated or reactivated, preventing inaccurate invoices and amounts. This ensures accurate financial reporting for our customers.
Original PR description
When updating a partner address that may impact the fiscal position, we need to ensure the fiscal position (and taxes) are also updated on running subscription or when reopening a churned subscription. Otherwise the subscription and generate invoices won't have the correct taxes and amount. opw-5365258 Forward-Port-Of: odoo/enterprise#103802
This update fixes an issue where the end of the pay period wasn't being calculated correctly for Mexican companies using specific payroll schedules (10 Days, 14 Days, Bi-weekly, Bi-monthly). The fix involves updating a key method to align with the standard calculation used in the core HR payroll module, ensuring accurate pay run period determination.
Original PR description
Bug: When we create a new pay run for a mexican company and we select the schedule "10 Days", "14 Days", "Bi-weekly" or "Bi-monthly", the end of the period is computed incorrectly. Cause: The standard method changed but it wasn't updated in the mexican payroll module. Fix: Change the signature of the method to match the one in hr_payroll. Task: 5421825 Forward-Port-Of: odoo/enterprise#104039 Forward-Port-Of: odoo/enterprise#102326
This update resolves an issue where the payroll rule parameter module would generate a technical error when configured with a future date. The fix ensures that computed fields are properly initialized, preventing the traceback and guaranteeing accurate calculations for payroll rules. This improves the stability and reliability of the payroll processing.
Original PR description
Steps to reproduce: -------------------------------- 1. Install `hr_payroll` module without demo 2. Go to Payroll > Configuration > Rule Parameters 3. Create a new rule parameter with code 4. In…
Steps to reproduce:
--------------------------------
1. Install `hr_payroll` module without demo
2. Go to Payroll > Configuration > Rule Parameters
3. Create a new rule parameter with code
4. In history page select the date in future
Observation:
--------------------------------
Traceback occurs:
```
File '/home/odoo/odoo/community/odoo/orm/fields.py', line 1456, in __get__
raise ValueError(f'Compute method failed to assign {missing_recs}.{self.name}')
ValueError: Compute method failed to assign hr.rule.parameter(2,).current_value_one_line
```
Issue:
--------------------------------
https://github.com/odoo/enterprise/blob/bbf53fbfc19e4c422cfefabd4689fc0f5156d359/hr_payroll/models/hr_rule_parameter.py#L88-L106 The compute method assigns values only inside conditional blocks. When both conditions fail, the method exits without assigning any value to the computed fields, causing a compute error
Solution:
--------------------------------
Initialize the computed fields with `False` before the conditional logic. If the second condition is met, the correct value is then assigned. This prevents the traceback and ensures proper field computation.
opw-5438500
Forward-Port-Of: odoo/enterprise#104346
Forward-Port-Of: odoo/enterprise#102924This update fixes an issue where customer statements incorrectly showed zero amounts due in certain reconciliation scenarios. The fix ensures that the system accurately considers partially reconciled invoices and payments when determining follow-up actions. This improves the accuracy of customer statements and reporting.
Original PR description
**Steps to Reproduce:** 1. Create an invoice with a due date 20 days prior and an amount of $100 2. Create a payment of 120$ 3. Create an invoice of 100$ 4. Reconcile the second invoice with the…
**Steps to Reproduce:** 1. Create an invoice with a due date 20 days prior and an amount of $100 2. Create a payment of 120$ 3. Create an invoice of 100$ 4. Reconcile the second invoice with the payment 5. Go to the customer record. 6. The Customer Statement smart button shows an amount due, but the followup status in the Accounting tab shows "No action needed". [Video (with different values, same result)](https://drive.google.com/file/d/1MFg-tUos-oGbk7SKn92OE8w0-PnObae7/view?usp=sharing) **Cause:** - The query in `_get_followup_data_query` checks an account.move.line's `balance`, ignoring amounts partially reconciled. [1](https://github.com/odoo/enterprise/blob/da8a0fb49861a5cfb366c85da459876ad1556924/account_followup/models/res_partner.py#L404) - In the example above, the sum of unreconciled balances is 100 - 120 = -20 due, where the amount_residual shows 100 -20 = 80 due. **Solution:** Use `amount_residual` instead of `balance` in `_get_followup_data_query`. This fix was applied last year to 17.0, but was never forward-ported to master. [2](https://github.com/odoo/enterprise/pull/77679) [opw-5216007](https://www.odoo.com/odoo/project.task/5216007) Forward-Port-Of: odoo/enterprise#104337 Forward-Port-Of: odoo/enterprise#101874
This update resolves a minor issue in the invoice import process where the wrong company's purchase tax was sometimes selected when importing invoices in a business with multiple companies. This has been fixed to ensure accurate tax calculations across all company setups. The fix was part of a larger refactoring effort.
Original PR description
In v18.4, the invoice import has been refactored with these 2 PRs: - [189979](https://github.com/odoo/odoo/pull/189979) - [75327](https://github.com/odoo/enterprise/pull/75327) This introduced a small bug where, in a multi-company setup, an `account.tax` could be selected from the wrong company when `_fetch_mail()` was called from the cron `Mail: Fetchmail Service` or if the method was called manually from the wrong company. Ticket: opw-5375785 Forward-Port-Of: odoo/enterprise#104075 Forward-Port-Of: odoo/enterprise#103190
This update corrects a terminology issue in our accounting reports. Specifically, it replaces instances of 'VAT' with 'tax' across various locations, ensuring consistent and accurate reporting for US and international users. This change improves clarity and avoids confusion related to tax terminology.
Original PR description
In the US and many other countries, the term "VAT" doesn't really exist. Most countries have their own term to refer to a sales tax or other types of taxes and have already adjusted it via translations. Given that we can't create a translation for en_US just to translate VAT -> Tax, we have to swap the few places that refer to taxes as VAT to actually use tax as it is a more universal term than VAT. task-5401292
This update resolves an error that prevented users from creating and saving bank statements within the accounting module. The issue stemmed from a problem accessing data within the system, now corrected by using a more reliable method for data retrieval. This ensures a smoother experience when managing bank transactions.
Original PR description
We get an owl error: `TypeError: Cannot read properties of undefined (reading 'root').` The code tries to read data from this.env.model, but it is undefined. Steps To Reproduce: 1. Install `account_accountant` 2. Go to Accounting Dashboard > Bank > `...` > Transactions 3. Open in the list view 4. Select any number of transactions 5. Type something in the statement field of one of the rows 6. Press Create and Edit to create a new Statement 8. Save the statement Ticket [link](https://www.odoo.com/odoo/project.task/5352277) opw-5352277 Forward-Port-Of: odoo/enterprise#104072 Forward-Port-Of: odoo/enterprise#101232
This update fixes a display issue in search results, now consistently showing a helpful 'Domain is invalid' message instead of errors. Additionally, the search logic has been optimized for better performance and allows users to easily filter for records that don't meet specific criteria (e.g., 'Is Not Set').
Original PR description
Search method logic was rewritten so since commit:
https://github.com/odoo/odoo/commit/92301a5b300dec1ddfca44dc35318b83d67c56fa
`raise NotImplementedError(_("some text"))`
no longer raises an error nor does it ever show the error message. Instead a notification that says "Domain is invalid. Please correct it" is always displayed when the method is unable to run the search. Therefore we update the legacy way of doing it in these search methods so that the code is clean (i.e. so no one copies it) and to avoid translating strings that will never be visible.
Additionally, the search logic was also updated such that the `value` exists is no longer needed and the `=`/`!=` operators are handled by `in` for optimized code. This change makes it so users can now do the "Is Not Set" search since it will return only the records that do not match the "Is Set" logic.
Forward-Port-Of: odoo/enterprise#104213
Forward-Port-Of: odoo/enterprise#104115This update resolves a technical issue that caused a traceback error when using pivot tables within Odoo's spreadsheet functionality. The fix ensures pivot tables now function correctly, regardless of the data dimensions used, improving spreadsheet usability for users. This improves data analysis and reporting.
Original PR description
Task: 5085724 Forward-Port-Of: odoo/enterprise#103369
This update resolves an issue where FrontDesk hosts with limited access were unable to check out visitors via email. The fix allows the checkout process to run with elevated permissions, ensuring all hosts can successfully complete the visitor checkout. This improves the user experience for FrontDesk staff.
Original PR description
Steps to reproduce: * Create a visitor record with a host who has only FrontDesk user access. * Ensure Notify with Email is enabled on the station. * Click Check Out Visitor from the received email → access error appears. Issue: * Hosts with only FrontDesk user access received an access error when clicking the “Check Out Visitor” button from the email notification. * They were unable to complete the visitor checkout process. Fix: * Run the checkout action with sudo() so the host can successfully check out the visitor from the email link. Impact: * Hosts can now check out visitors without encountering permission errors. task-5373026 Forward-Port-Of: odoo/enterprise#104250 Forward-Port-Of: odoo/enterprise#101179
6 changes
Resolved issues and error corrections
This update resolves an issue where refreshing AI content triggered unnecessary cron jobs. It also includes error handling to prevent embedding failures, ensuring chunks are marked as failed instead of halting the entire process. This improves the reliability and efficiency of the AI embedding feature.
Original PR description
Avoid triggering multiple embedding cron jobs when the refresh button is clicked, since the cron is automatically triggered while new chunks still need to be processed. Also catch AttributeError exceptions when calling the embedding service and mark the affected chunk as failed instead of crashing the whole embedding flow. task-id-5498693
Users were experiencing blocks in the Point of Sale UI due to printers ignoring print requests. This change reverts a previous update that introduced this issue, allowing print jobs to function correctly and unblocking users. It's a quick fix to restore normal POS functionality.
Original PR description
Since preparation printers are ignoring the print job requests sent a lot of users are being blocked in pos UI. This reverts commit 5e290c264f14108e036344663fc459bf77da265e. This unblocks the user's UI in case of a duplicate print Odoo: https://github.com/odoo/odoo/pull/243981
This update resolves an issue where copying headings in the knowledge editor caused URL redirection problems. It also improves the editor's responsiveness by reducing unnecessary layout adjustments triggered by mouse movements. These changes enhance the overall stability and usability of the knowledge editor.
Original PR description
### [FIX] knowledge: prevent heading link id duplication on copy/paste Prior to this commit, copy/pasting a heading would preserve its `data-heading-link-id` resulting in mismatches for URL redirections. After this commit, such ids are always reset to guarantee unicity. ### [FIX] knowledge: throttle mousemove for heading link button Prior to this commit, every `mousemove` event could cause a layout trashing to reposition the heading link button. After this commit, the repositioning is debounced at a more reasonable rate. task-5384684 Forward-Port-Of: odoo/enterprise#101445
This update fixes an issue where appointment dates were displayed out of order in the online booking cart. The original fix inadvertently reversed the date order due to how appointment dates were formatted. The change ensures dates are correctly presented, improving the user experience for booking appointments.
Original PR description
**Steps to produce:** - Install `appointment,website_sale` modules. - Go to website > appointment > Online Cooking Lesson. - Book a slot > Proceed to payment. - Open the cart. **Issue:** - The…
**Steps to produce:** - Install `appointment,website_sale` modules. - Go to website > appointment > Online Cooking Lesson. - Book a slot > Proceed to payment. - Open the cart. **Issue:** - The appointment dates are displayed in an incorrect order in the cart. **Root cause:** - In the linked commit, the logic reverses the `self.name` lines to fix a display issue. - However, since appointment dates are split across multiple lines, reversing the list also unintentionally reverses the appointment date order. **Solution:** - Ensure that the appointment dates are formatted to appear on a single line, preventing them from being split into multiple list entries and incorrectly reordered when the lines are reversed. [commit]: https://github.com/odoo/odoo/pull/223433/changes/5b69176e64e6a4cc46966a8c41b675ed3d98dd0a Before: <img width="554" height="138" alt="image" src="https://github.com/user-attachments/assets/3e13a2a5-61d5-48c5-8e6a-85f313f7b6ca" /> After: <img width="566" height="120" alt="image" src="https://github.com/user-attachments/assets/f0b04592-7fd4-4104-b200-cf9b6f080962" /> opw-5420805 ---
This update fixes formatting issues in live chat ticket descriptions created by the chatbot. Previously, system notifications were included, making descriptions difficult to read. Now, only relevant chat messages are used, ensuring clearer and more organized ticket information.
Original PR description
In [1], chat bot's create lead/ticket steps were improved to set the formatted discussion as the lead/ticket description. The same holds for lead/ticket commands. However, the /ticket command was not properly updated. As a result, the discussion is poorly formatted, making it difficult to read. Also, the description should only include relevant messages, not system notifications such as "agent joined the channel". This commit fixes both issues. task-5491212 community: https://github.com/odoo/odoo/pull/243856
This update fixes a confusing error message displayed when cash point closing with Fiskaly fails. The new message now includes the detailed response from Fiskaly, allowing users and support teams to quickly diagnose and resolve issues related to cash point transactions. This improves the user experience and streamlines troubleshooting.
Original PR description
When a cash point closing fails with Fiskaly, the error message shown to the user was not very informative. This commit enhances the error message to include the actual response from Fiskaly, making it easier for users to understand what went wrong. opw-5461084
11 changes
Resolved issues and error corrections
This update corrects a technical issue preventing the IoT Box from functioning correctly as a kiosk. The change ensures that browser arguments are properly passed, resolving a memory-related freeze. This improves the stability and reliability of the kiosk functionality.
Original PR description
In odoo/odoo#233676 we switched from `chromium-browser` to `chromium` to adapt to new executable name in raspbian. We also need to update this name in the check to set the arguments of the browser, or they will never be passed. This fixes the issue where the IoT Box freezes when using it for kiosk, as the browser was eating all the memory.
This update corrects a technical issue where invoice XML files generated for EU standard e-invoicing (Peppol Bis 3.0) were incorrectly using the company's VAT number instead of its company registration number. This change ensures invoices comply with Belgian regulations and accurately reflect the company's identification details. The fix prioritizes using the company registry information for key identifiers.
Original PR description
The base `_get_party_node` uses `commercial_partner.ref` for `PartyIdentification` and `commercial_partner.vat` for `CompanyID`. There was no logic to prefer `company_registry` when available. Refs:…
The base `_get_party_node` uses `commercial_partner.ref` for `PartyIdentification` and `commercial_partner.vat` for `CompanyID`. There was no logic to prefer `company_registry` when available. Refs: An independent invoice example: https://developer.vertexinc.com/einvoicing/docs/belgium-example-documents https://github.com/odoo/odoo/blob/40c862476382c68d7f452284074f5b44955d1f98/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_20.py#L1564-L1566 https://github.com/odoo/odoo/blob/40c862476382c68d7f452284074f5b44955d1f98/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_20.py#L1585 Steps To Reproduce: - Have accounting, account_edi_ubl_cii and contacts installed. - Create a Belgian company and set the VAT, Company ID and Reference (under Sales & Purchase tab). - Create a contact and set his eInvoice format in Accounting tab to EU Standard (Peppol Bis 3.0) and make sure to give him a country. - Go to accounting -> Customers -> Invoices and create an invoice for the contact you created. - Send the invoice to the contact and download the XML from the chatter and inspect it. - PartyIdentification/ID shows the partner's ref field value (e.g., "(odoobe)") instead of the company registration number. - PartyLegalEntity/CompanyID uses the VAT number instead of the company registration number (ondernemingsnummer). Ticket [link](https://www.odoo.com/odoo/project.task/5418190) opw-5418190
This update corrects a bug where loyalty points weren't accurately calculated when re-loading saved Point of Sale (PoS) orders. Previously, changes to the order after saving didn't update the point totals. This fix ensures that points are correctly awarded based on order changes, improving the customer loyalty program experience. This is a critical fix for accurate point tracking.
Original PR description
When an order was saved then reloaded in the PoS, the points awarded for a loyalty program were not computed correctly. Steps to reproduce: ------------------- * Create a loyalty program that gives one point for every € spent * Activate the trusted pos option in the PoS settings * Open a PoS session and create an order * Add 1 product A for a total of €10 * Set a partner * You should get 10 points * Save the order * Reload the saved order * Change the quantity of product A to 2 > Observation: You still have 10 points instead of 20 Why the fix: ------------ When saving the order, it is synced with the backedn and the comboLines are reloaded from the backend when reloading the order. However, it becomes an empty list and the line would be treated as a combo header. This backport a part of this commit : https://github.com/odoo/odoo/pull/220828 opw-5118716 Forward-Port-Of: odoo/odoo#241674
This update prevents users from modifying attached documents or custom fields on locked sales orders. Previously, changes made to product documents within a locked order were not saved, causing confusion. This fix ensures consistency and prevents unintended modifications when a sale order is locked for reporting or other purposes.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Enable the `Lock Confirmed Sales` option from settings 2. Create a new quotation and add a customer 3. Add a product that includes a document that has its…
Versions -------- - 18.0+ Steps ----- 1. Enable the `Lock Confirmed Sales` option from settings 2. Create a new quotation and add a customer 3. Add a product that includes a document that has its visibility set to `Inside quote pdf` 4. Modify which documents (header, product document, etc) are attached to the quotation and their custom fields from the `Quote Builder` tab 5. Confirm the quotation and notice that the sale order is now locked Issue ----- Although the sale order is locked, you are still able to add/remove the documents, and you can also modify the custom fields. Adding/removing the headers and footers work as expected, however if you try to add or remove a product document it will look like your modification has been successful, but if you refresh the page you will discover it hasn't actually been saved. Even though you can't add or remove a product document, you still can modify the custom fields for these product documents. Cause ----- You are allowed to edit the headers, footers, and custom fields because there are no checks to stop you from doing so if the sale order is locked. The reason that adding or removing product documents doesn't work is that these are saved on the sale order line, which becomes read only when the sale order is locked. Solution -------- When the sale order is locked, disable adding/removing documents or modifying custom fields. It is only disabled from the frontend similarly to other fields in the locked sale order. opw-5182258
This update resolves an issue preventing electronic invoices in Latin American countries from correctly generating PDF documents with the expected headers and footers. The fix ensures the invoice templates use the correct country-specific information, addressing a problem with older databases that lacked chart template settings. This ensures accurate invoice generation for Latin American businesses.
Original PR description
This commit fixes a bug introduced here https://github.com/odoo/odoo/commit/3f7d79731fd5e5a751f7f1aeae63379c6211de5c because some old databases do not have set the chart template so it is needed to render the header and footer of the report template layouts taking in consideration the account fiscal country code instead of the chart template. Replicate printing the pdf of a customer electronic invoice on an argentinen company without chart template. Ticket Adhoc side: 105739 Task latam: 1373 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update removes a redundant warning related to credit notes from the GSTR report, streamlining the reporting process. Previously, a warning appeared on invoices when a credit note was confirmed, which has now been corrected to clear only after the credit note is fully posted and checked. This simplifies reporting for users.
Original PR description
This **PR** removes the credit note warning from the GSTR report, as it is not required at the report level. Additionally, when this warning is present on an invoice and the credit note is confirmed, the credit note is set to not checked. The warning will only be cleared once the credit note is posted and checked task-5469000
This update optimizes how Odoo's Point of Sale system interacts with its database, specifically IndexedDB. Previously, syncing large amounts of data, like loyalty card information, could slow down adding products to a cart. This change improves the overall speed and responsiveness of the Point of Sale experience.
Original PR description
Before this commit, if a model had a large number of records, for example, loyalty card, the synchronization of IndexedDB could be slow, leading to performance issues when adding products to the cart. opw-5232087 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a technical issue related to managing user consent for online accounts. The change allows users to more effectively control their data synchronization settings, addressing a potential error that previously prevented consent management. The update also enhances the system's flexibility by allowing it to work with different data providers.
Original PR description
In this commit:https://github.com/odoo/enterprise/commit/bf5b7d03fe8e138ee8bc0246d3d148638db5d620 we introduce a message on the account_online_link to be able to manage the consent. But since manage_consent is not a field of account.online.linki would traceback, we changed the position of the code by popping the value. Also changed the url to use the provider_type to be able to use the route with any provider if needed task-5187621 Forward-Port-Of: odoo/enterprise#102428
This update fixes an issue where custom button snippets weren't consistently shown in the editor interface. The fix ensures that custom buttons are correctly displayed and avoids incorrect wrapping in paragraph tags, improving the usability of the website editor.
Original PR description
### Issue: When a custom button snippet was dropped next to an existing button wrapped in a `<div>`, it was incorrectly and unconditionally wrapped in a paragraph `<p>` tag. This issue did not occur…
### Issue: When a custom button snippet was dropped next to an existing button wrapped in a `<div>`, it was incorrectly and unconditionally wrapped in a paragraph `<p>` tag. This issue did not occur with standard button snippets or when the buttons were wrapped in a `<p>` tag. ### Steps to reproduce: 1. Drag a standard "Button" snippet next to an existing button (e.g., in the navbar). The structure is correctly `<a/><a/>`. 2. Save a button as a custom snippet. 3. Drag this new custom button snippet next to a button wrapped in a `<div>` (navbar in our example). 4. Observe the structure: `<div><a/><p><a class="s_custom_snippet"/></p></div>`, but it should be like `<div><a/><a class="s_custom_snippet"/></div>`. ### Fix The logic has been corrected to only wrap a button snippet in a paragraph tag if it has no sibling buttons and is not already inside a `<p>`. This ensures consistent behaviour between standard and custom button snippets. A tour test is also added, ensuring the behaviour is correct. Backport of https://github.com/odoo/odoo/commit/3a8f2cc418510c3b91f8b9086bb4a89a1745e40d task-[5032130](https://www.odoo.com/odoo/project/974/tasks/5032130) Forward-Port-Of: odoo/odoo#224476
A technical issue with WebKit was preventing users from properly scanning barcodes on iOS devices. This resulted in a white square obscuring the scanning area. This update resolves the problem by addressing a WebKit bug, ensuring accurate barcode scanning functionality for iOS users.
Original PR description
Issue ----- There is an issue in WebKit with mix-blend-mode https://bugs.webkit.org/show_bug.cgi?id=286619 Because of this issue, in barcode, the user gets a solid white square over the scanning zone, so they don't see the barcode being scanned. ----- Ticket: opw-5386846 Forward-Port-Of: odoo/odoo#243486
This update optimizes the SQL query used to generate the budget report, resulting in significantly faster performance, especially when dealing with large amounts of data. The change avoids a slow query strategy and allows for a more efficient join process, leading to quicker report generation times.
Original PR description
Before this commit, the SQL query generated in `_get_aal_query` utilized a `LEFT JOIN` with a complex `OR` condition on the join clause: `(bl.company_id IS NULL OR bl.company_id = al.company_id)`.…
Before this commit, the SQL query generated in `_get_aal_query` utilized a `LEFT JOIN` with a complex `OR` condition on the join clause: `(bl.company_id IS NULL OR bl.company_id = al.company_id)`. Because this condition lacks a strict equality constraint, the planner cannot build a hash table for the join. Consequently, it is forced to fallback to a Nested Loop Join strategy, evaluating the condition as a filter for every row pair. This results in significant performance degradation on large datasets. This commit optimizes the query by splitting the logic into two separate `SELECT` statements combined with a `UNION ALL`: 1. Matches where `company_id` is explicitly equal. 2. Matches where `company_id` is NULL. By separating these conditions, the planner can now prioritize a Hash Join for the equality check and handle the NULL join separately, significantly reducing execution time. References: - Original PR introducing the logic: https://github.com/odoo/enterprise/pull/82955 - Plan Before (Join Filter): https://explain.dalibo.com/plan/a55476hgb73ea7g6#plan - Plan After (Hash Cond): https://explain.dalibo.com/plan/3b9g484569a86efb#plan opw-5460862
3 changes
Resolved issues and error corrections
This update resolves a bug where imported sales orders containing kit products were incorrectly splitting items into individual lots, causing problems within the Point of Sale (POS) system. The change prevents this splitting behavior when a kit product is sold, ensuring accurate POS transactions. This improves the reliability of sales processing.
Original PR description
When a kit product with tracked components is sold, and if the kit is tracked by lots, the imported sale order lines were being split by lots causing issues in the POS session. Although kits are not supposed to be tracked by lots, this commit prevents the splitting of sale order lines by lots when the product is a kit. opw-5423833 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A technical issue with WebKit (the browser engine) was preventing users from properly scanning barcodes on iOS. This resulted in a white square obscuring the scanning area. This update resolves the problem by addressing the underlying WebKit bug, ensuring accurate barcode scanning for iOS users.
Original PR description
Issue ----- There is an issue in WebKit with mix-blend-mode https://bugs.webkit.org/show_bug.cgi?id=286619 Because of this issue, in barcode, the user gets a solid white square over the scanning zone, so they don't see the barcode being scanned. ----- Ticket: opw-5386846 Forward-Port-Of: odoo/odoo#243486
This update resolves a technical error that occurred when users clicked the back button after adding a video to a course using the website_slides module. The issue stemmed from a conflict between the template and how the system rendered elements, preventing a smooth user experience. This fix ensures consistent functionality and avoids potential disruptions for users.
Original PR description
Steps to reproduce: 1. install `website_slides` 2. Go to any course and click `Add content` > `Video` 3. Click on back button Issue: - When only website_slides is installed a traceback occurs `Error: The rendered template 'website.slide.upload.modal.select' contains multiple root nodes that will be ignored using renderToElement, you should consider using renderToFragment or refactoring the template.` Cause: - The template `website.slide.upload.modal.select` contains multiple root elements, but the code uses `renderToElement`, which expects a single root element. https://github.com/odoo/odoo/blob/4876a54e8cfb3a115b5423db102fc2b7a40b196a/addons/website_slides/static/src/xml/website_slides_upload.xml#L15-L36 Solution: - wrap template's elements inside a div opw-5457124