Friday, April 24, 2026
38 changes · saas-19.1
Resolved issues and error corrections
This update resolves an issue where automated tests would fail due to incorrect data being used during retries. The fix ensures that test instances are properly initialized, allowing cross-module tests to run reliably. While a more permanent solution is planned, this update immediately restores the functionality of key tests.
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 fixes a bug where toggling the 'website_published' status on a new event would unexpectedly disable it. The issue stemmed from how Odoo handles field updates, specifically when a field is protected. This change ensures the 'website_published' status remains consistent, preventing unexpected behavior and improving event visibility.
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
This update resolves an issue where channel mentions stopped functioning correctly. A technical error allowed a faulty code merge, but this commit corrects a typo that was the root cause of the problem. This ensures channel mentions continue to work as expected.
Original PR description
Forward-port of PR introduced regression where channel mention was no longer working [1]. There was a bug on runbot that didn't prevent merging code with failed test. This commit fixes the typo. [1]: https://github.com/odoo/odoo/pull/260457
This update clarifies the Helpdesk stage Kanban view by removing the confusing 'Days to rot' number. This change ensures users can more easily understand the status of helpdesk tickets, leading to improved efficiency and communication. The change was a simple fix to improve usability.
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#114781
This update fixes a visual issue where call layout buttons (like Fullscreen) didn't have reduced opacity when not hovered. The fix adjusts the CSS to correctly apply a slight opacity reduction, ensuring consistent visual feedback for all buttons in the call view. This improves the user experience by making the call layout more intuitive.
Original PR description
Recent commit fixes an issue where items like Fullscreen in call menu had reduced opacity when this should only affect layout buttons in call view [1]. To do so it limits the opacity to the layout…
Recent commit fixes an issue where items like Fullscreen in call menu had reduced opacity when this should only affect layout buttons in call view [1]. To do so it limits the opacity to the layout actions, but the style was not applied because ActionList has more CSS specificity that requires using `--o-mail-ActionList-Button-opacity` variable for the non-hover opacity value. Since this was not defined, this default to opacity 100%, thus not applying the reduced opacity when not mouse-hovering. This commit fixes the issue with `--o-mail-ActionList-Button-opacity` of `.75`, so that opacity is slightly reduced when no mouse-hovering. [1]: https://github.com/odoo/odoo/pull/259866 Before / After (mouse-hover on "Picture-in-Picture", see lack of visual distinction) <img width="58" height="32" alt="Screenshot 2026-04-22 at 11 21 47" src="https://github.com/user-attachments/assets/e04b0f8c-c754-4ea4-8870-752610418587" /> <img width="57" height="28" alt="Screenshot 2026-04-22 at 11 21 25" src="https://github.com/user-attachments/assets/a5aa9987-ddaf-45f8-9e2a-260fd04dcfb9" /> Forward-Port-Of: odoo/odoo#260599
This update resolves an issue where the 'cancel' button within a confirmation dialog wasn't functioning as expected. Now, clicking the cancel button properly dismisses the confirmation, ensuring a smoother user experience. This prevents users from being inadvertently locked into a confirmation process.
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 documents spreadsheet functionality wasn't properly triggering 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 corrects a bug 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 resolves an issue impacting how taxes are displayed and processed.
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#260616
This update ensures that custom fields used in Odoo's related field functionality are properly configured. Previously, a field needed to be searchable to be usable in this way. This change streamlines the process by directly checking the field's properties, preventing issues during upgrades and ensuring consistent behavior across Odoo.
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. Previously, the untaxed amount was incorrectly displayed. The fix ensures accurate calculation by correctly identifying discount amounts as tax-excluded, resolving a discrepancy of 0.02.
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 fixes an issue where employees were incorrectly paid 80% for rest days when they had sick leave spread across the weekend. The change ensures that employees are paid their full wage on rest days, aligning with the definition of a sickness day and standard payroll practices. This ensures accurate and compliant payroll calculations.
Original PR description
Currently, if a sick leave is spread over a weekend, the work entry type set on the saturday and sunday will be the sick leave type. If an employee is entitled sickness allowance (which is paid 80%), it means that we will be paying them 80% for their rest days as well. However, as per the definition, a sickness day is a day on which an employee is absent from work by reason of being unfit due to injury or sickness. If an employee is not expected to be at work (rest day), that day cannot be considered a sickness day. If this rest day is paid (which is done by default in our module), we should thus pay the full wage on that day and not a reduced 80%. task-6079736 Forward-Port-Of: odoo/enterprise#113486
This update ensures that the VIES summary reports generated for Czech companies include only the numeric VAT number, as required by official regulations. Previously, the reports incorrectly included the country code ('CZ'), which could cause issues with data processing. This change corrects the report format to align with VIES standards.
Original PR description
**Steps to reproduce:** - Install the `l10n_cz_reports` module and switch to a `CZ Company` - Create an invoice for a customer with a VAT number, add a product, and set the Transaction Code (enable…
**Steps to reproduce:** - Install the `l10n_cz_reports` module and switch to a `CZ Company` - Create an invoice for a customer with a VAT number, add a product, and set the Transaction Code (enable it from the optional columns if needed). - Navigate to Reporting > VIES Summary Report. - Observe the value in the `VAT Number` column (includes country code). - From the dropdown, export the report as XML. **Observation:** In the generated XML file, the `c_vat` field contains the VAT number including the country code (e.g., `CZ12345679`) instead of only the numeric part (`12345679`). **Root cause:** At [1], the VAT number is directly taken from the report lines without removing the country code. **Fix:** This commit ensures that the `c_vat` field contains only the VAT number without the country code, complying with the official VIES XML format requirements. Ref: https://adisspr.mfcr.cz/dpr/adis/idpr_pub/epo2_info/popis_struktury_detail.faces?zkratka=DPHSHV#:~:text=Tax%20identification%20number%20of%20the%20purchaser%20(only%20the%20numeric%20part) [1]: https://github.com/odoo/enterprise/blob/c4f2c3442f30f5ac972dd136a3642acc5bcc6da2/l10n_cz_reports_2025/models/l10n_cz_vies_summary_handler.py#L29-L62 opw-6093259 Forward-Port-Of: odoo/enterprise#114730 Forward-Port-Of: odoo/enterprise#113083
This update corrects an issue where lead conversions sometimes created duplicate company entries, leading to incorrect data relationships. The fix ensures that company creation is handled correctly using the existing `parent_name` flow, 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
This update corrects a recent change that removed currency information from bank payment records. Without this currency field, the system couldn't accurately track monetary amounts in different currencies. This fix ensures correct financial reporting and reconciliation within the Enterprise module.
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
This update resolves a migration issue by requiring the 'survey' module to be installed before upgrading to the 'esg_csrd' module. Previously, users without 'survey' would automatically install it, causing problems with data migration. Now, the system only installs 'survey' if it's already needed for the 'esg_csrd' module.
Original PR description
Description of the issue this commit addresses: As survey is a dependency but not an auto_install requirement of esg_csrd only from 19.0, when migrating to that version, users that don't have survey installed but do have esg will auto_install survey and pull a new computed stored field, ResUsers.karma which causes migrations issues as no script was made to account for that scenario. --- Desired behavior after this commit is merged: This commit adds survey in the auto_install requirements for the module so only instances that already have ResUsers.karma can auto_install esg_csrd --- runbot-238524 Forward-Port-Of: odoo/enterprise#113905
This update resolves an issue where certain images, particularly those with CORS protection, weren't being optimized to the WebP format when multiple images were selected. This ensures that all media assets are efficiently optimized, leading to faster loading times and reduced bandwidth usage. This aligns with our ongoing efforts to improve website performance.
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 corrects an issue where emails sent from the applicant refusal wizard were not populating with the correct applicant information. The fix ensures that the email subject and body now accurately reflect the chosen template and the specific applicant details, improving communication and accuracy in the recruitment process. This resolves a technical problem that prevented proper notification of applicants.
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 consistent label printing 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 resolves a technical issue that prevented a key test from running correctly, ensuring the stability of our reporting functionality. The change ensures tests are properly configured, preventing future errors and maintaining the reliability of Odoo's financial reports. This improves the overall quality and dependability of the system.
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 fixes an issue where custom background colors weren't consistently applied to mailing templates with rounded text blocks. The change ensures that the Content Background color picker correctly reflects the background color of text blocks, resolving a visual inconsistency. This improves the overall appearance and usability of mailing templates.
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 fixes an issue where the forecast report incorrectly grouped purchase orders with different receipt dates for the same product. The fix ensures that each unique receipt date is accurately represented in the forecast details, providing a more precise view of inventory availability. This improves the reliability of inventory planning.
Original PR description
If you make a purchase order with 2 quantity of the same product, and set 2 different receipt date. The forecast report details would incorrectly group them as the same line. Steps to reproduce: ------------------- * Create a purchase order * Add 2 lines with the same product * Change the receipt date for one of the 2 lines * Go to the forecast report of the product > Observation: In the forecast details there is only one line for the first receipt date. Why the fix: ------------ We add a condition in the `_sameDocument` function to check that the 2 documents being compared have the same receipt date opw-5361583 Forward-Port-Of: odoo/odoo#254170
This update fixes a minor issue where the company logo wasn't appearing on the journal audit report export templates. The fix ensures the necessary 'o_content' class is included in the template, correctly applying the logo. This improves the visual consistency and professionalism 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
A technical issue with the 'Gelato: Order status update' email template was resolved. The system's automatic HTML normalization caused an error when rendering the template, preventing users from editing the email. The fix temporarily removed a problematic element to ensure the template can be saved.
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 previously archived. Now, sale orders can successfully include archived products, improving the flexibility and usability of the POS system. This change was made to ensure a smoother and more reliable experience for users.
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 resolves an issue with the channel mention feature in Odoo, ensuring it functions correctly. The team has cleaned up the underlying code to enhance reliability and performance. This improves the user experience when collaborating through channels.
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
A minor bug preventing the generation of EC sales return reports was resolved. This fix stemmed from a typographical error introduced during a recent update to the ec sales list report. This ensures accurate reporting of returns for online sales.
Original PR description
With the rework of the ec sales list report(https://github.com/odoo/enterprise/commit/4096c1fcbd7f31f70153058d2e3f9eab6d82e356#diff-2f90e40d6e7b35681a4af03037e8e5ee0fddab2ba0876d9f148bf79786a91c29), the return generation of this type became generic but a small bug appeared. It was not generating anymore because of a typo.
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 a smoother user experience.
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, mirroring the behavior of regular attachments. Previously, signed documents defaulted to 'My Drive,' creating confusion and inconsistent document organization. This change improves workflow and simplifies document management 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 fixes a technical issue related to how our system processes data sent through Peppol, a key European payment network. By adding a new field to track the movement state, we ensure accurate reporting and future-proof our integration with Peppol's evolving response types. This enhances the reliability of our Peppol transactions.
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 resolves a visual inconsistency where styling applied to images (like rounded corners or shadows) was incorrectly carried over when users switched to using icons instead. Now, when an image is replaced with an icon, the styling classes are automatically removed, ensuring a cleaner and more consistent look across the To-do app and other areas of Odoo.
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 an issue where employees assigned to the 'Administration' department weren't automatically added to relevant discussion channels. The change ensures that the channel subscription is triggered immediately when the employee's department is updated, streamlining team communication and ensuring accurate channel membership.
Original PR description
**Steps to reproduce:** navigate to 'Discuss' > 'Channels' create a new channel and set 'Auto Subscribe Departments' to 'Administration' create a new user and a corresponding employee record go to 'Employees' > locate the employee set the employee's department to 'Administration' **Current behavior before PR:** The user is not automatically added to the channel. This occurs because the auto-subscription logic is triggered before the department change is committed to the database. **Desired behavior after PR is merged:** The user is correctly auto-subscribed to the channel once the department update is saved. task-5448649 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261110 Forward-Port-Of: odoo/odoo#241617
This update fixes a problem where payment reminder emails for subscriptions were missing the subscription's end date. The fix ensures that all payment reminder emails, regardless of how they're sent (automatically or manually), accurately display the subscription's closing date. This improves the clarity and accuracy of payment notifications.
Original PR description
### Issue before this commit: When sending a payment reminder email for a subscription using the email composer, the template was not correctly populated with the expected dynamic values. In…
### Issue before this commit: When sending a payment reminder email for a subscription using the email composer, the template was not correctly populated with the expected dynamic values. In particular, fields such as the subscription closing date and the subscription code were missing. ### Steps to reproduce the issue: 1. Install subscription and go to that app 2. Open one subscription 3. Send message > Load template: "Subscription: Payment Reminder" 4. Sentence is incomplete: missing end date of the subscription ### Cause of the issue: The issue was caused by the absence of a proper context injection when rendering the email template from the mail.compose.message wizard. The template relied on context variables like date_close, but these values were not being computed nor passed during manual email composition. Unlike automated flows, the composer did not provide the subscription-specific context required by the template. ### Reason to introduce the fix: The fix makes the payment reminder and closing templates self-sufficient by replacing context-based values with fields and helper methods directly available on the subscription record. A dedicated method is introduced to compute the subscription close date consistently, so the templates render the expected values both in automated flows and when manually loaded from the email composer. opw-6031613 Forward-Port-Of: odoo/enterprise#111801
This update fixes a minor issue in the website editor where the round corners option would disappear when the border width was set to zero. The change ensures the round corners 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 fixes an issue where the 'Hide lines at 0' setting caused the Trial Balance report to omit its report-level 'Total' line when printed. The change ensures that all report totals, including the root total, are consistently displayed during printing, improving report accuracy and clarity for users.
Original PR description
When "Hide lines at 0" is enabled, printing e.g. the Trial Balance will drop the report-level "Total" line when printing. This commit fixes that. The issue was introduced in this commit[^1], which didn't consider total lines without a parent (i.e. root total lines). [^1]: https://github.com/odoo/enterprise/commit/7fec18b99eb2aa5ebc357dcad5f95f234db5b7d8 Forward-Port-Of: odoo/enterprise#114084
This update resolves a test failure related to the work order tour, specifically when users interact with form views. The fix ensures all popups are fully closed before the tour concludes, preventing data inconsistencies and improving test reliability. This enhances the overall stability of the Odoo Enterprise system.
Original PR description
**Issue** Currently, there is an async issue with the test `test_shop_floor_disable_serial_create`that may fail with the following error: "Tour finished with a dirty form view being open. Dirty form views are automatically saved when the page is closed, which leads to stray network requests and inconsistencies." **Cause** Although the tour explicitly closes all popups, the last click on the discard button may not be processed before the tour ends: https://github.com/odoo/enterprise/blob/859e65e8c267701bb19dbff9d24a8c80774dbaa6/mrp_workorder/static/tests/tours/tour_shopfloor.js#L332-L333 runbot-242504 Forward-Port-Of: odoo/enterprise#114367
This update corrects a misleading issue in the Z report generated from date ranges. Previously, the report header incorrectly displayed information for a single closed session even when data from multiple sessions (including open ones) was included. This change ensures the report header accurately represents the sessions contributing to the report's data.
Original PR description
Before this commit: - When generating a Z report via date range (config_ids, no session_ids), the header's session name was derived from the closed-session if there was exactly one, which excludes open sessions (stop_at IS NULL). - If an open session had completed orders (state='done') within the date range, those orders were included in the report body while the session itself was absent from the sessions list. - This caused the header to display the closed session's name and title the report as a single-session Z report, even though it contained data from multiple sessions. opw-6123054 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259900
This update resolves a crash that occurred when assigning recruiters in the Odoo Recruitment Kanban view. The issue stemmed from an unnecessary cache parameter in avatar image URLs, which caused errors due to missing data. Removing this parameter ensures the Kanban view functions correctly and reliably.
Original PR description
**Steps to Reproduce:** 1. Open Recruitments 2. Find a job position without a recruiter in the kanban view. 3. Clicking on the assign recruiter widget produces a traceback. **Bug Cause:** The…
**Steps to Reproduce:** 1. Open Recruitments 2. Find a job position without a recruiter in the kanban view. 3. Clicking on the assign recruiter widget produces a traceback. **Bug Cause:** The ?unique= cache related parameter was added to the avatar image URL in the autoCompleteItem slot of KanbanMany2OneAvatarEmployeeField. This parameter relies on write_date being available on the autocomplete suggestion record. However, web_name_search only returns id and display_name, so write_date is undefined on autocomplete suggestion records, causing a crash when accessing autoCompleteItemScope.record.data.write_date.ts. **Bug Solution:** Remove the ?unique= parameter from the avatar image URL in the autoCompleteItem slot, reverting it to its original form. Cache is unnecessary for autocomplete suggestion avatars as they are only visible for the duration of the dropdown interaction. **Task:** 6092768 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261040
This update resolves an issue where product category images weren't showing on website B when accessed without being logged into website A. The fix ensures category images use absolute URLs, bypassing domain-based access restrictions, resulting in consistent image display across all websites.
Original PR description
Scenario: - set two website A and B with different domain - create an eCommerce category Y - create and publish a product with category Y, website B - drop category list widget in a page in website B - set in /odoo/system-parameters web.base.url to domain of website A - open the page in website B while being logged out of website A Result: the category Y image is dead. Cause: category images are using domain of "web.base.url", so if that corresponds to a website where the category is not shown (because of the access rule "Hide empty eCommerce categories to public/portal users") then the image will not be shown (unless we are a logged in internal user on the domain of "web.base.url"). Fix: use absolute URL without domain for category image, the same way it is done for other dynamic snippets (eg. Products). opw-6118004 Forward-Port-Of: odoo/odoo#260124