Friday, April 24, 2026
48 changes · saas-19.2
Enhancements to existing features
This update fixes an issue where product names on the Replenishment dashboard were being cut off, leading to a poor user experience. The pull request adjusts column widths to ensure product names are fully visible, improving readability and usability. This change enhances the efficiency of inventory management.
Original PR description
Purpose: the name of the product in the replenishment dashboard often gets truncated which is bad for UX. Adjust column widths to make better use of space. task-5097352 Forward-Port-Of: odoo/odoo#259259 Forward-Port-Of: odoo/odoo#253384
Resolved issues and error corrections
This update resolves an issue where automated tests would fail due to incorrect data being used during retries. Specifically, tests involving multiple modules were affected. The fix ensures the test environment is properly initialized, improving test reliability and preventing disruptions.
Original PR description
Regenerating the test instance on retry works in most cases but fails when the test instance contains relevant data about what to test, which is the case for cross module tests and test params. Combined with an error while disabling autoretry this caused the hoot test to retry with an empty list. Fixing the issue by setting the relevant flags. This is a quick fix to reenable the test but a more robust solution would be to make sure ALL test instance existing attributes are properly copied before starting the test, or forbidding to set them on the instance before running them. Forward-Port-Of: odoo/odoo#261130
This update corrects a display issue in the Odoo Enterprise portal. Previously, running subscription amounts were incorrectly shown as the total billing amount. Now, the portal sidebar accurately displays the next billing amount for each running subscription, providing users with clearer and more accurate billing information.
Original PR description
Running subscriptions were showing the total amount in the portal sidebar title instead of the next billing amount. Display the next billing amount for running subscriptions. task-6125080
Steps to reproduce ================== - Install hr_payroll - Use a mobile viewport - Go to Employees - Open a record - Switch to the Salary Adjustments notebook tab => TypeError: undefined is not an object (evaluating 'props.activeActions.onDelete=this.onDelete.bind(this)' Cause of the issue ================== The SalaryAttachment2ManyField widget overrides the rendererProps to handle the delete action, but this isn't defined on mobile (because a kanban view is used) See
Original PR description
Steps to reproduce ================== - Install hr_payroll - Use a mobile viewport - Go to Employees - Open a record - Switch to the Salary Adjustments notebook tab => TypeError: undefined is not an…
Steps to reproduce ================== - Install hr_payroll - Use a mobile viewport - Go to Employees - Open a record - Switch to the Salary Adjustments notebook tab => TypeError: undefined is not an object (evaluating 'props.activeActions.onDelete=this.onDelete.bind(this)' Cause of the issue ================== The SalaryAttachment2ManyField widget overrides the rendererProps to handle the delete action, but this isn't defined on mobile (because a kanban view is used) See https://github.com/odoo/odoo/blob/9f93f22ed5f6d5dbbafeb0a8c6fababdc2a65d45/addons/web/static/src/views/fields/x2many/x2many_field.js#L196-L212 Solution ======== Since there is no delete action on the kanban view, there is no need for an override. While we are at it, there was no kanban view defined. Thus a default view was used https://github.com/odoo/odoo/blob/138fad6d54a0b59885b1e5c712beb8f581c9555c/odoo/addons/base/models/ir_ui_view.py#L2835-L2846 It only contained the field description. Since that one is optional, records without a description were almost invisible.. Thus we also add a basic kanban view opw-6047295 Forward-Port-Of: odoo/enterprise#113317
This update fixes an issue where users couldn't insert snippets into website forums by clicking on snippet groups. The fix allows snippet group clicks, treating them as a fallback option when other dropzones are unavailable, ensuring snippet insertion remains possible. This improves the forum editing experience.
Original PR description
Steps to reproduce the issue: - Go to Forum, then go to the Help page - Enter Edit mode - Try to drag and drop a snippet => The dropzone in the s_cover at the top of the page are available - Try to click on a snippet group => Nothing happen, because all dropzones are filtered The s_cover element has the [data-snippet] attribute. When clicking on a snippet group, the editor filters out dropzones inside other snippets. Since s_cover is treated as a snippet, its dropzones are excluded, even though they are the only ones available on the page. The solution is to treat dropzones inside snippets as low priority instead of strictly forbidden. If no other valid dropzones exist, we allow these as a fallback to ensure snippet insertion remains possible. task-5938138 Forward-Port-Of: odoo/odoo#259709 Forward-Port-Of: odoo/odoo#256078
This update resolves a test failure (runbot error 242012) that stemmed from the test relying on demo data. The changes ensure the test now operates independently, improving the reliability of our automated testing process. This prevents potential issues when running tests against the standard Odoo environment.
Original PR description
runbot error: 242012 (lasted error in `Post install tests for pos_restaurant -> !sale`: resolved) Forward-Port-Of: odoo/odoo#255497
A bug was causing night shift templates to incorrectly span an extra day. This update corrects a calculation error within the shift scheduling process, ensuring that night shifts accurately reflect the intended working hours and duration. This resolves a potential overestimation of shift times, improving scheduling accuracy.
Original PR description
Issue: ---------------------------------------- Creating a night shift from a template produces a shift spanning over one additional day. Steps to reproduce: ----------------------------------------…
Issue: ---------------------------------------- Creating a night shift from a template produces a shift spanning over one additional day. Steps to reproduce: ---------------------------------------- - Create a planning shift template form 23h to 1h the next day (2h) - It must have a span over 2 working days - Create a shift and use this template - The shift spans over one more day Cause: ---------------------------------------- In `_calculate_start_end_dates()`, we call `plan_days()` with `start` having the hours specified. So in `plan_days()` when retrieving the worked days, the first day is ignored because the resource is not supposed to be working from 23h to 1h (considering their calendar). Then we count two days, and so the end date is offset by one day. Solution: ---------------------------------------- We should call `plan_days()` without the hour specified so we make sure the first day is included in the count. opw-6134844 Forward-Port-Of: odoo/enterprise#114616
This update prevents customers without a portal account from seeing the 'Pay Now' button in follow-up emails. This change avoids confusion and ensures customers aren't directed to a process they can't complete, improving the overall user experience. It aligns with best practices for customer onboarding.
Original PR description
If a customer has no portal account, the pay now button added to follow-up emails won't allow them to access any invoices on the portal. Even if they register afterwards, a separate account will be created and they won't have access to those invoices. To avoid confusion, this commit hides the pay now button when the customer has no portal account. task-6075621 Forward-Port-Of: odoo/enterprise#114698 Forward-Port-Of: odoo/enterprise#112891
This update resolves an issue where the 'cancel' button within the spreadsheet functionality didn't properly trigger the confirmation process. Now, clicking the cancel button will correctly halt the operation, ensuring a smoother user experience. This improves data integrity and user satisfaction.
Original PR description
The `cancel` callback of the `env.askConfirmation` method was not called when the user clicked on the cancel button. task-6074948 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#260061
This update resolves an issue where the 'cancel' button within the spreadsheet functionality didn't properly trigger the cancellation process. The fix ensures that clicking the cancel button now correctly removes the user's changes and returns them to the previous state. This improves the user experience and data integrity.
Original PR description
The `cancel` callback of the `env.askConfirmation` method was not called when the user clicked on the cancel button. task-6074948 Forward-Port-Of: odoo/enterprise#112987 Forward-Port-Of: odoo/enterprise#112304
This update resolves an issue where invoice settlement would fail if the commercial partner information wasn't fully loaded. The fix now directly uses the partner ID from the invoice data, streamlining the process and preventing errors. This ensures smoother invoice settlement operations.
Original PR description
Before this commit, it was possible that commercial_partner_id was not loaded, which caused an error when settling an invoice. This commit fixes the issue by avoiding the need to load the full partner record. Since only the partner ID is required to load the account move, it is now read directly from the raw data, which already includes the ID. opw-6023150 Forward-Port-Of: odoo/enterprise#114110 Forward-Port-Of: odoo/enterprise#111957
This update ensures that custom fields used in related paths must be searchable, resolving a previous issue that prevented certain field combinations from working correctly. This change improves the consistency and reliability of related field usage within Odoo, preventing potential disruptions. The update also optimizes the check to avoid impacting upgrade processes.
Original PR description
Following up on #259309. A field must be searchable to be used in the related path. To know it, we must go into the instantiated field on the model to read that property, as being stored is not necessary. This mixes two different levels of abstraction but is necessary to have more consistent behaviour and not to block valid related field going through searchable fields. We also do this check only when the registry is ready to avoid blocking upgrades. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260585
This update fixes a calculation error related to early payment discounts on invoices. Previously, the untaxed amount was incorrectly displayed. The fix ensures accurate calculation of the untaxed amount when early payment discounts are applied, particularly with 'Always (upon invoice)' tax settings.
Original PR description
Steps to produce: --- - Install the `Sales` module. - Go to `Invoicing > Configuration > Payment Terms`. - Open `Immediate Payment` and enable Early Discount. - Set `Reduced Tax` to `Always (upon…
Steps to produce: --- - Install the `Sales` module. - Go to `Invoicing > Configuration > Payment Terms`. - Open `Immediate Payment` and enable Early Discount. - Set `Reduced Tax` to `Always (upon invoice)`. - Go to Invoicing > Configuration > Taxes. - Create a 21% tax with `Tax included`. - Create a product with a sale price of 7.50 and assign the tax. - Create a Sale Order with this product > Set Immediate Payment as payment term. Issue: --- - The untaxed amount is computed as 6.22 instead of 6.20. Root cause: --- - At [1], in `_add_base_lines_for_early_payment_discount`, the base lines generated for early payment discount were missing the `special_mode='total_excluded'`. - Consequently, the tax engine interpreted these amounts as tax-included and attempted to recompute the untaxed base, resulting in an incorrect untaxed amount. Solution: --- - Add `special_mode='total_excluded'` to the base lines created for early payment discount computation. - This ensures the discount amounts are treated as already tax-excluded. [1]https://github.com/odoo/odoo/blob/a2b4f618328f3ce3f654fd2c1ee4410365706a7e/addons/sale/models/sale_order.py#L515-L550 opw-6023472 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260480 Forward-Port-Of: odoo/odoo#255724
This update resolves a problem where demo invoices couldn't be accessed correctly due to a user account restriction. The fix replaces the demo user with a standard, always-available user, ensuring demo data can be reliably accessed and used. This improves the stability of the demo environment for testing and training.
Original PR description
Steps to reproduce: ------------------- 1. Create a new trial DB with demo data and French localization 2. Archive Marc Demo if you create the DB locally (this happens automatically on Odoo.com…
Steps to reproduce: ------------------- 1. Create a new trial DB with demo data and French localization 2. Archive Marc Demo if you create the DB locally (this happens automatically on Odoo.com trials due to the user seat limit probably) 3. Select the demo company only (unselect the main one) 4. Open Accounting and click the Sales journal from the dashboard Access Error about reading Marc Demo. Unarchiving him would work around this issue. Why the bug ----------- The sales demo invoices set invoice_user_id to Marc Demo (base.user_demo). Marc Demo belongs to the main company and can't be read from another company when archived. On 19.0 this did not break because the avatar widget only needed display_name (read with sudo). Commit https://github.com/odoo/odoo/commit/3732ca85b03bea9eabfb05cc306ce0bf5bac88d4 added write_date to it for cache busting, so now the read is real and the rule fails. The fix ------- Use base.user_admin instead: it's never archived, so it stays readable from any company. opw-6106870
This fix addresses an error preventing access to demo data within Odoo trial accounts. The issue stemmed from demo user accounts being archived, which caused conflicts when demo data was accessed from separate companies. The solution changes the demo user assignment to ensure consistent access regardless of archiving status.
Original PR description
Steps to reproduce: ------------------- 1. Create a new trial DB with demo data and French localization 2. Archive Marc Demo if you create the DB locally (this happens automatically on Odoo.com…
Steps to reproduce: ------------------- 1. Create a new trial DB with demo data and French localization 2. Archive Marc Demo if you create the DB locally (this happens automatically on Odoo.com trials due to the user seat limit probably) 3. Select the demo company only (unselect the main one) 4. Open Accounting and click the Purchases journal from the dashboard Access Error about reading Marc Demo. Unarchiving him would work around this issue. Why the bug ----------- demo_invoice_deferred and demo_bill_deferred set invoice_user_id to Marc Demo (base.user_demo). Marc Demo belongs to the main company and can't be read from another company when archived. On 19.0 these records only existed in the main company, where Marc Demo is accessible. Commit 9aed0c0135d7b084dee544c6566fad96c62ec1fd migrated the demo to `template`, so now they are created in every company. Still, it only breaks because of commit [3732ca85b03b](https://github.com/odoo/odoo/commit/3732ca85b03b), which added write_date to the avatar widget for cache busting. Before, the widget only needed display_name (read with sudo), so the rule was not checked. The fix ------- Use base.user_admin for demo_invoice_deferred (never archived, stays readable from any company), and False for demo_bill_deferred (a bill has no salesperson). opw-6106870
This update fixes a display issue where reports (like invoices and purchase orders) weren't showing correctly for users in time zones ahead of UTC. The change ensures that reports accurately reflect the order date in the user's local time, resolving a discrepancy that prevented timely reporting.
Original PR description
Why this commit: When loading the 'bills to receive' or 'Invoices to be Issued' The time zones ahead of UTC will face the discrepancy in the view. e.g. etc/GMT-12 timezone is 12 hours ahead of UTC,…
Why this commit: When loading the 'bills to receive' or 'Invoices to be Issued' The time zones ahead of UTC will face the discrepancy in the view. e.g. etc/GMT-12 timezone is 12 hours ahead of UTC, So 12 AM UTC is 12 PM etc/GMT-12. So report view will not include the invoices/bill with order_date of current day till its 12 AM[next day] IN UTC, Meaning etc/GMT-12 will be seeing today's bills/invoices after 12 PM. After this commit: To resolve this discrepancy we use the context_today date to get the user local date. Which is required by the [domain sanitizer](https://github.com/odoo/odoo/blob/8bff78853f6ab8dc2cc951c03bb30181c0745834/odoo/orm/domains.py#L1572-L1574) too. Steps to reproduce (Possible in runbot) : 1. Select etc/GMT-12 timezone in preferences [when UTC is between 13:00-24:00 ~ 1:00-12:00 GMT-12(of next day)] 2. Create a PO and Validate the quantity received. 3. Go to accounting>review>bills to receive. 4. the newly created PO won't be listed here. OPW: 6083526 Forward-Port-Of: odoo/enterprise#114763
This update simplifies the way our Slovak reports handle XML data. By using the standard XML parsing library, we've reduced unnecessary processing overhead and improved the efficiency of the system. This change ensures consistent and reliable report generation.
Original PR description
Removes the custom XMLParser configuration in favor of the default etree parser. This reduces unnecessary overhead and ensures we are using the standard library's recommended defaults for processing XML content. Forward-Port-Of: odoo/enterprise#114828
This update resolves an issue where image optimization (specifically converting to WebP) wasn't consistently applied to images from CORS-protected sources. Previously, users selecting multiple images through the media dialog would miss out on this optimization. This change ensures all images, regardless of origin, are optimized for faster loading times and reduced bandwidth usage.
Original PR description
Since [1], when users select multiple images through the media dialog, subsequent images of a CORS protected image are not converted to webp. This commit fixes that issue. Related to task-5405262 [1]: https://github.com/odoo/odoo/commit/422b073bcc6406c76339a1ccaa0c40dc3f42801c Forward-Port-Of: odoo/odoo#261055
This update resolves an issue where emails sent from the applicant refusal wizard incorrectly displayed placeholder values instead of the actual applicant information. The fix ensures that the email body now accurately reflects the selected template and applicant details, improving communication and reducing potential confusion for recruiters. This change ensures accurate and informative notifications regarding applicant rejections.
Original PR description
Issue: ---------------------------------------- The `applicant.get.refuse.reason` wizard displays the mail body with the placeholders, not the values actually sent. Steps to reproduce: ---------------------------------------- - Open Recruitments and go to an applicant form view - Click "Refuse" - Select the template "Job already fulfilled" - The subject and the mail body have placeholder values Cause: ---------------------------------------- We don't render the body for the wizard, only when we send the mails. Solution: ---------------------------------------- Render the body when we get it from the template. This only works if `applicant_ids` have one value. Otherwise, we display the placeholders because the values can be different from an applicant to another. opw-6082883 Forward-Port-Of: odoo/odoo#258874
This update resolves an issue where users without 'write' access to products couldn't print labels. The fix adds necessary permissions to allow read-only users to generate product and variant labels, improving usability for a wider range of users. This ensures all users can access this key sales functionality.
Original PR description
Users who do not have the "write" access on `product.template` and `product.product` cannot print product labels and product variant labels Steps to reproduce: 1. Install Sales 2. Log in as Marc Demo…
Users who do not have the "write" access on `product.template` and `product.product` cannot print product labels and product variant labels Steps to reproduce: 1. Install Sales 2. Log in as Marc Demo 3. In Sales > Products > Products, open a product and click Print Labels from the cogwheel menu 4. An access error is raised Same issue happens for Product Variants Issue: https://github.com/odoo/odoo/commit/95ace0a694eaf83329b50e6b89f774f0c59fec5e removed Products-related rights from the `base.group_user`. This made a difference in terms of access rights, as the `IrActionServe.run` method checks for the "write" access by calling `_can_execute_action_on_records`: https://github.com/odoo/odoo/blob/d15685304f479541879fabd55ea1cae4252a2a90/odoo/addons/base/models/ir_actions.py#L1230-L1239 Solution: Add `group_user` to the `group_ids` of the relevant actions to prevent the check on the "write" access from being performed This is a backport of https://github.com/odoo/odoo/commit/6c2c353f30db05579f5e8b7a6752ec2d1ae365b2 opw-6111333 Forward-Port-Of: odoo/odoo#260513 Forward-Port-Of: odoo/odoo#260342
This update fixes a problem where newly created events would unexpectedly have their website visibility turned off. The issue stemmed from an internal system process incorrectly resetting the event's website publication status, even when it should have been automatically managed. This change ensures the website visibility is correctly set upon event creation.
Original PR description
If you create a new event, and immediately toggle "website_published" before it is saved, the UI will toggle it off on its own. The reason is technical. As event tracks this field, it is read everytime the record is written to. In parallel `_finalize_publication` invalidates the website_published field even when it is protected. As the field is protected, the orm does not recompute the field when it is read but does fill in the cache with `False` even though it would have evaluated to `True` if computed. The issue here lies in invalidating a protected field, as `Environment.protecting` normally guarantees that the field will not be invalidated. We now stop invalidating protected records. task-6102144 Forward-Port-Of: odoo/odoo#257826
This update fixes an issue where child contacts of German companies were incorrectly flagged as companies when the l10n_de_reports module was installed. The change ensures that only companies with their own distinct commercial entities are recognized as such, improving the accuracy of German VAT reporting.
Original PR description
Problem: When l10n_de_reports is installed, child contacts of a German company are incorrectly considered as companies as well. Steps to reproduce: 1. Install l10n_de_reports. 2. Create a company with a German VAT number (e.g. DE123456789). 3. Create a child contact under that company. 4. The child contact will be incorrectly considered as a company. Cause: If l10n_de_reports is installed, any partner with a German VAT number (DE + 9 digits) is considered as a company. Since child contacts share the same VAT as their company, they would be considered as companies as well, which is not correct. However, a partner should only be considered as a company if they are their own commercial entity. https://github.com/odoo/odoo/blob/e6bd6b106c376336594edd868c09505032008ac1/odoo/addons/base/models/res_partner.py#L819 Forward-Port-Of: odoo/enterprise#114600
This update removes an outdated requirement to include country information on payment tokens used for subscription invoices. Previously, this caused processing issues with some payment providers. This change simplifies the invoicing process and aligns with current payment provider requirements, improving efficiency.
Original PR description
Before this commit, a country was mantadory on the payment token when it was used to pay invoices of subscriptions. This behavior was fetched back from internal code in 15.3. This issue was not visible until recently. Some token are fine without country, the provider allows it but the cron fails to process the sale order when the contract is processed. THis commit remove that old constraint. opw-5268156 task-5349998 Forward-Port-Of: odoo/enterprise#113715 Forward-Port-Of: odoo/enterprise#100166
This update fixes an issue where signature overlays were causing data loss in PDF documents. Now, the original PDF structure, including metadata and bookmarks, is fully preserved when signatures are added. This ensures consistent and accurate PDF documents for our users.
Original PR description
Instead of rebuilding the PDF by copying content, metadata, and bookmarks, we now duplicate the original document first and then apply the signature overlays. This ensures the full structure and settings are preserved without loss. task-6083291
This update ensures that the unit of measure (UoM) specified for a supplier's information related to a product variant remains consistent across all other variants of the same product. Previously, this could lead to errors when creating purchase orders. This change improves data accuracy and simplifies the purchasing process.
Original PR description
Make sure any UoM defined on a supplierinfo having a specific variant cannot be used by other variant of the same product template Task: 6042382 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#259213
This update resolves an issue where taxes that automatically replaced themselves were being hidden from account move reports. The change ensures that all taxes, including those that self-replace, are accurately reflected, improving the accuracy of financial reporting. This ensures consistent and reliable financial data.
Original PR description
If a tax replaces itself, it's not redundant and must appear on account moves. This commit solves this issue by including self-replacing taxes in the name_search. task-6147767 Forward-Port-Of: odoo/odoo#261044 Forward-Port-Of: odoo/odoo#260616
This update resolves a technical issue within the account reports testing process. A previous test failure was missed by the automated system, leading to instability. This change ensures tests run correctly and reliably, maintaining the quality and stability of the account reporting functionality.
Original PR description
This test, when run alone, raised an error telling assigning directly self.env.companies was not the right way of doing this, and it was better to create a new env. For some reason, it didn't raise when run together with other tests ; so, runbot didn't see the issue. This commit aims at soothing the ire of Odoo's mighty tests spirits \o/ Forward-Port-Of: odoo/enterprise#114248
This update resolves a bug where the 'Update Payment' button remained visible after processing batch payments for Mexican CFDI invoices. The issue stemmed from incorrect UUID comparisons during payment reconciliation, leading to the button's persistent display. This fix ensures the button disappears correctly when batch payments are processed.
Original PR description
- Create one invoice with the PUE payment policy. - Create another invoice with the PDD payment policy. - Send both invoices to the CFDI. - Create a batch payment for both and reconcile. - Click on Update Payment on one of the invoices. The Update Payment button does not disappear. In the method _l10n_mx_edi_cfdi_invoice_get_payments_diff, we compare the current UUIDs and the previous UUIDs to determine if the button should be shown. However, when there is a batch payment, the current UUID list includes the UUIDs of all invoices in the batch, including the PUE payment (which should normally be filtered out by the continue). The previous UUID list includes only the UUID of the PDD payment. opw-6055781 Forward-Port-Of: odoo/enterprise#114261 Forward-Port-Of: odoo/enterprise#112520
This update fixes an issue where custom background colors in Mailings weren't consistently applied to text blocks with rounded corners. The fix removes a hardcoded background color and now correctly integrates with the Content Background color picker, ensuring consistent styling across different designs. This improves the overall visual experience for users.
Original PR description
The `o_mail_wrapper_td` element in the `ThemeWrapper` template had a hardcoded `bg-white` class. The intent was for the wrapper background to default to white, but doing it this way meant the color…
The `o_mail_wrapper_td` element in the `ThemeWrapper` template had a hardcoded `bg-white` class. The intent was for the wrapper background to default to white, but doing it this way meant the color didn't participate in the CSS variable system. Whenever a user set a custom Content Background color and a border-radius on a text block, the corners would reveal white underneath instead of the actual Content Background color. Removed the `bg-white` class from the template and set white as the proper default for the `--wrapper-background-color` variable instead, so the wrapper is still white by default but correctly responds to the Content Background color picker. Steps to reproduce: 1. Create a new Mailing 2. Set the Content Background color to something other than white 3. Add a Text block 4. Set a border-radius value on the block => white shows behind the rounded corners instead of the Content Background Ticket [link](https://www.odoo.com/odoo/project.task/5868955) opw-5868955 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247808
This update clarifies the Helpdesk stage Kanban view by removing the confusing "Days to rot" number. This change improves user understanding and simplifies the visual representation of helpdesk stages, leading to more efficient workflows.
Original PR description
Currently, only the “Days to rot” number is displayed, so users cannot understand what the number represents. In this commit, it hide from the helpdesk stage kanban view. task-5485507 Forward-Port-Of: odoo/enterprise#114880 Forward-Port-Of: odoo/enterprise#114781
This update fixes an issue where chatter message highlights were unexpectedly appearing on the employee form in Odoo Enterprise. The change restricts these highlights to only the 'review_state' field, improving the user experience and preventing unnecessary visual distractions. This ensures a cleaner and more focused interface.
Original PR description
The dropdown_selection_badge widget was triggering chatter message highlights on hover for all its usages (e.g. Dimona). Add an opt-in highlight_chatter attribute so only the review_state field on the employee form triggers this behavior. task-6131035
This update fixes a minor issue where the company logo wasn't appearing on the journal audit export template. The fix ensures the necessary styling class ('o_content') is correctly applied, resulting in consistent and accurate reporting. This improves the visual presentation of financial reports.
Original PR description
before this commit, the export template of the journal audit was missing the o_content and so the company logo class was not applied opw-6128819 Forward-Port-Of: odoo/enterprise#114782
This update fixes an issue where invoices incorrectly showed as 'Paid' after a check was voided. The change ensures that the invoice payment state reverts to 'not_paid' when a check is voided, preventing incorrect payment records. This improves data accuracy for financial reporting.
Original PR description
Steps to reproduce: 1- Install l10n_ar and l10n_latam_check modules 2- Switch company to (AR) Responsable Inscripto 3- Go to [Accounting -> Configuration -> Journals -> Bank] and make sure 'outstanding payments account' is set in outgoing payments for own checks and manual payment 4- Go to [Accounting -> Vendors -> Bills] and create a new bill 5- Create an own check payment for the full amount 6- Go to the check and void it Description of issue: When you view the invoice after voiding the check, it's payment state will be shown as 'Paid' Expected behavior: Invoice payment state should go back to 'not_paid' Why this happens: When the check is voided, it's `amount_residual` attribute becomes 0. This causes `pay.is_matched` to be True, and as a result `all_payments_matched` attribute is also True. This turns the invoice payment state to paid. opw-6016394 Forward-Port-Of: odoo/odoo#256118
A technical issue with the 'Gelato: Order status update' email template was resolved. The system's automatic HTML normalization caused errors when rendering the template, specifically related to a loop evaluating tracking data. The fix temporarily removes a problematic paragraph element to ensure the template functions correctly.
Original PR description
**Steps to reproduce:**
- Go to Technical > Email > Email Templates
- Try to edit and save "Gelato: Order status update"
- QWebError is raised: `KeyError: 'tracking_data'`
**Issue:**
Browser html normalization silently move block elements such as `<ul>` outside `<p>` when rendering the template body_html as it is invalid html. This moved the `t-foreach="ctx['tracking_data']"` evaluation outside the surrounding `<t t-if="ctx.get('tracking_data')">` which triggered the error.
**Fix:**
Removed `p` element to use the outer `div` and avoid the issue for now.
related: https://github.com/odoo/odoo/commit/b24974d64c3afe5febdad9abff9cb23a333f1ada
similar: https://github.com/odoo/odoo/pull/256605
opw-6114223
Forward-Port-Of: odoo/odoo#259548This update resolves an issue where loading sale orders from the point-of-sale (POS) system would fail if the order contained products that had been marked as archived. Now, sale orders can successfully include archived products, providing greater flexibility in managing inventory and sales data. This change was made to improve the usability of the POS system.
Original PR description
Before this commit, loading a sale order from pos would raise an error if the order contained a product that had been archived. opw-6116760 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260638
This update corrects a recent change that removed the currency field from batch payment records. This ensures accurate monetary reporting and reconciliation by associating payments with their correct currency, resolving a potential data inconsistency. This fix improves the reliability of financial data within the Odoo Enterprise system.
Original PR description
This commit: https://github.com/odoo/enterprise/commit/301f63597b0c21fef16a1941314ac95602c8f01f removed some currency id field from the account bank statement and so the monetary field didn't have the currency anymore task-6131298 Forward-Port-Of: odoo/enterprise#114369
This update fixes a bug in the Czech localization module (`l10n_cz`) that prevented the city field from appearing on contact forms. The fix ensures accurate address data collection for Czech businesses, resolving a usability issue and improving data integrity. This ensures compliance with Czech reporting requirements.
Original PR description
**Steps to reproduce:** * Install `l10n_cz` module. * Go to Contacts and open or create a contact with country set to Czech Republic. * Observe the address fields on the contact form. **Observed behavior:** * The city field is not visible nor editable on the contact form. * The city field is also missing on invoice partner address for Czech localization. **Cause:** * `cz_partner_address_form` in `res_partner_views.xml` overrides the standard address layout but omits the `city` field entirely, causing it to be hidden for all contacts using the Czech address format. * ref : https://github.com/odoo/odoo/commit/8d362c26051e08ccbe79b9e1d6e4ad096379d6fc **Fix:** * Add the `city` field back between `street2` and `zip` in `cz_partner_address_form`, consistent with the standard Odoo address format and with the same `readonly` condition applied to the other address fields. opw-6125766
This update resolves a test failure related to the leaderboard settings within the timesheet grid. The change ensures that the necessary system calls are executed correctly when the leaderboard feature is enabled, improving the stability and reliability of the timesheet reporting.
Original PR description
This commit checks the steps expected once the leaderboard settings in timesheet grid is enabled to make sure the RPCs called are correctly done as expected. runbot-error-243315
This update corrects an issue where lead conversions sometimes created duplicate company entries, leading to incorrect customer hierarchies. The fix ensures that company creation is handled correctly using existing logic, preventing this duplication and maintaining data integrity.
Original PR description
**Issue:** When converting a lead with both `contact_name` and `partner_name`, the created contact end up with a duplicate company hierarchy, producing an invalid chain like: Person A < Company < Company **Cause:** `_create_customer()` was creating a company from `partner_name` in addition to the normal `parent_name` flow already handled by `res.partner.create()`, so the same company name was effectively used twice. **Fix:** Remove the extra company creation and let the existing `parent_name` behavior create the company once, then attach the contact to it directly. Task-6105653 Forward-Port-Of: odoo/odoo#259300
This update resolves a technical issue related to how channel mentions were handled in follow-up messages. The team has cleaned up the implementation, ensuring that channel mentions function correctly and reliably. This improves the overall communication experience within Odoo.
Original PR description
Follow up of https://github.com/odoo/odoo/pull/261083 This commit provides a cleanup of the channel mention feature fix. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261185
This update fixes a technical issue where the Timesheets assistant was storing outdated suggestions in local storage, leading to performance problems. The change automatically removes suggestions older than 30 days, optimizing the system and improving the user experience.
Original PR description
In the Timesheets assistant, we store the suggested events taken or dismissed by the user to avoid suggesting them again. However, there is no mechanism to remove them from the localstorage, so it currently grows infinitely. With this PR, we now delete events older than 30 days, to avoid filling the localstorage with useless data. Task-6131640 Forward-Port-Of: odoo/enterprise#114562
This update ensures our system correctly processes new types of data being sent through Peppol, a key European payment network. By adding a common field to track the movement state, we're prepared for future Peppol updates and maintain seamless integration with this important payment system. This enhances our ability to support evolving payment standards.
Original PR description
With the addition of new peppol_move_state for the Application Responses in Peppol, some checks to know wether the move was sent through Peppol were not updated. This commit does that by adding a common field for it. This is usefull as we might add some extra peppol_move_state values in the near future (Peppol supports more response types than we currently offer to our users). Forward-Port-Of: odoo/odoo#258598
This update fixes an issue where styling applied to images (like rounded corners or shadows) was incorrectly carried over when replacing an image with an icon in the To-do app. Now, styling is automatically removed, ensuring icons always display with their intended, clean appearance. This improves the visual consistency of the application.
Original PR description
### Steps to Reproduce: - Go to the To-do app and create a new task. - Upload an image. - Apply shape styling to the image (e.g., rounded, shadow, img-thumbnail). - Replace the image with an icon. ### Description of the issue/feature this PR addresses: - When an image had shape applied (such as rounded, rounded-circle, shadow, or img-thumbnail) and was replaced with an icon, those classes were carried over to the icon. ### Desired behavior after PR is merged: - Since these classes are specific to image shape styling, they are now removed when an image is replaced with an icon. task-6007631 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259611 Forward-Port-Of: odoo/odoo#258060
This update fixes a minor issue in the website editor where the 'round corners' option would disappear when a border wasn't present. The change ensures the option remains visible regardless of border settings, improving the user experience and allowing for consistent design choices.
Original PR description
Steps to reproduce: - Open the website editor. - Select a block with the border configurator and round corners enabled. - Set the border width to 0 px. => The Round Corners option is hidden. Before this commit, the change introduced by [1] hid the option when no border was set. This restriction was not needed because a block can use a border radius without a visible border. After this commit, the option remains visible when round corners are supported, even without a border. [1]: 97e8cc8d664e66ba62e8282a67f069805682ae41 task-6089515 Forward-Port-Of: odoo/odoo#260633
This update resolves an error that occurred when users attempted to access ticket links after an attendee was removed from an event. The fix prevents a technical error (IndexError) by gracefully handling empty attendee lists, ensuring ticket links always function correctly.
Original PR description
Currently, an error occurs when accessing the ticket link after the related attendee has been deleted. **Steps to Reproduce:** - Install the **Events** module. - Create a new event. - Create an attendee with a valid email ID. - Make sure the email is sent successfully. - Delete the attendee for the event. - From the received email, try to click on the **"View Tickets"** link. **Error:** `IndexError - tuple index out of range` **Cause:** The controller filters registrations using the provided `registration_ids`, but when the attendee is deleted, the resulting recordset becomes empty. It raises an error when trying to access the first element of an empty recordset. **Fix:** This commit handles empty recordsets by returning early when no registrations are found. sentry-7357927405 Forward-Port-Of: odoo/odoo#256310
This update ensures that signed documents attached to project tasks or projects are automatically saved to the project's designated Documents folder, rather than defaulting to 'My Drive'. This improves organization and consistency for users managing documents within projects.
Original PR description
Steps to Reproduce --- - Request a signature from a project task or project and complete the signing process. - In the chatter, click "Add to Documents" on the signed attachment. Issue --- Signed documents attached to projects or tasks default to "My Drive" when added to Documents, instead of using the project's configured Documents folder. Current Behaviour --- - Regular task/project attachments correctly preselect the project Documents folder. - Signed attachments fall back to "My Drive". Expected Behaviour --- Signed documents linked to projects or tasks should preselect the project's Documents folder, consistent with regular attachments. Fix --- Extend get_documents_operation_add_destination to handle sign.request attachments linked to project.task or project.project, resolving to the corresponding project Documents folder. task - 5226770 Forward-Port-Of: odoo/enterprise#105600
This update resolves a technical issue that caused the payroll system to crash when employee bank account information was incomplete. The fix ensures the system handles missing data gracefully, preventing errors and maintaining the accuracy of CFDI reports. This improves system stability and data reliability.
Original PR description
Accessing the employee bank accounts using index [0] raised an IndexError when no accounts were defined. Additionally, computing the CLABE flag using len() caused a TypeError when the account number was missing. This change uses a safe recordset slice to avoid accessing empty records and guards the length check to only evaluate when a value is present. It prevents crashes while keeping the original behavior unchanged and avoids sending invalid empty values in the CFDI. Forward-Port-Of: odoo/enterprise#113987
This update resolves an issue preventing users from exporting General Ledger reports (FEC files) when using custom date ranges. The fix ensures date ranges are properly formatted for export, preventing errors and improving report generation reliability. This ensures reports can be exported without interruption.
Original PR description
Since https://github.com/odoo/enterprise/commit/40484f985f511edd7ba2ae759ce63ef564bcf1f7 we have a custom_ranges option in the date filter. It needs to be sanitized like the other dates in order to avoid errors when JSON-serializing the options for export. Steps: - Install l10n_fr_reports and select FR Company - Activate the 'Fiscal Years' options and create one - Open the General Ledger report - Try to export the FEC file -> Traceback when validating the wizard opw-6107374