Daily updates from Odoo
Wednesday, August 20, 2025
65 changes · saas-18.4
Resolved issues and error corrections
The point of sale checkout flow now respects auto-validation when a cashier uses Force Done on a terminal payment. This prevents staff from being stuck on the payment screen and sends them to the receipt as expected, making checkout smoother.
Original PR description
When doing a force done on a terminal payment, if the auto validation was turned on, it would not be triggered after clicking on the force done button. Steps to reproduce: ------------------- * Turn on the auto validation for terminal payments * Create a new order and add a product * Select a terminal payment method (You can fake the force done state as I did in the tour) * Click on the "Force Done" button > Observation: You are not redirected to the receipt screen. opw-4954406 Forward-Port-Of: odoo/odoo#223485 Forward-Port-Of: odoo/odoo#222867
Imported accounting entries with analytic distribution now avoid creating duplicate analytic items. This keeps reporting cleaner by ensuring the analytic item is created only when the accounting move is posted, while preserving the imported distribution data.
Original PR description
When importing an account move with analytic distribution, two analytic items are created, one at the creation of the move, and another when the move is posted. This happens because, when creating the move from an import, the line values passed include Commands to create analytic_line_ids, and not analytic distributions. Desired behavior: Only one analytic item should be created, and only when the move is posted. When the move is created, its lines' analytic distribution should be correctly filled based on the data imported. Solution: This commit unlinks the Analytic Lines created at move imports (removing the analytic_line_ids from moves at create/write), after the analytic distribution is set on the corresponding move line. task-4987799 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223300 Forward-Port-Of: odoo/odoo#222196
Fixed an issue where pages with multiple image galleries would only update the first gallery when visitors used carousel controls. Each gallery now has its own identifier, so all galleries work correctly and independently on website pages.
Original PR description
After the website refactor [1], the image gallery snippet (carousel) no longer had unique IDs. As a result, when multiple image galleries were present on the page, navigating any carousel other than the first would incorrectly update only the first one. This commit ensures that each image gallery snippet is assigned a unique ID, allowing all carousels to function independently and correctly. [1]: https://github.com/odoo/odoo/commit/9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2 Related to task-4367641
Invoices or vendor bills marked as blocked will no longer be automatically unblocked when payment status is recalculated during related accounting or inventory actions. This preserves user decisions and helps prevent blocked documents from moving forward unexpectedly.
Original PR description
Problem: When the `payment_state` field on `account.move` is automatically computed, the logic will prioritize whether the move has been posted over whether it has been blocked. The effect is that if…
Problem: When the `payment_state` field on `account.move` is automatically computed, the logic will prioritize whether the move has been posted over whether it has been blocked. The effect is that if an invoice has been marked as blocked, it might be automatically unblocked during reconciliation. Solution: The `_compute_payment_state` method will now prioritize a move's `payment_state` being blocked over whether it has been posted. This prevents a blocked move from being unblocked unexpectedly. Steps to Replicate (Runbot 18) - Create a product - Track inventory - Cost > 0 - Control policy = On ordered quantities - Product category is valuated in real-time (Inventory Valuation - Automated) (requires 'Stock Accounting Automatic' group) 1. Create a PO for the product 2. Create a bill, validate it 3. Block the bill using the contextual action 4. Receive the product If you navigate back to the Vendor Bill, you will see that it has been unblocked. opw-4981799 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223351 Forward-Port-Of: odoo/odoo#222906
The accounting dashboard now shows amounts needing review with the correct currency context for foreign-currency journals. This avoids confusion where a company-currency balance was displayed with the journal currency symbol, helping users interpret review amounts accurately.
Original PR description
Steps to reproduce: - create a new journal with foreign currency - create an invoice (amount:100) with this journal and set it "to check" - Go to dashboard Issue: check balance is in company currency…
Steps to reproduce: - create a new journal with foreign currency - create an invoice (amount:100) with this journal and set it "to check" - Go to dashboard Issue: check balance is in company currency amount but the symbol is the one from the currency of the journal Solution: ~~Chkl: Misc and Sales/Purchase Journals should display all amounts in company currency≃~ Eventually, we decided that it would be better for the stable versions to keep the currency displayed as the one from the journals. We therefore use the same logic as for the bill/invoices Note: As of 18.0 the logic has been inversed. The field is now `checked` and is unticked only if there are missing information. therefore, documents to_check -> checked=False As of 18.4, the checked is onaly available for bookeeper and accounting-admin. If you are one of these, the invoice will be considered as checked whenever it is posted. If you have only have the invoicing rights, when posting, the checked will not be set on True and will considered as to be reviewed by bookeeper and accounting admin. This does not change the validity of the test opw-4349684
The Point of Sale now ignores payment attempts that were canceled on a payment terminal when matching incoming terminal confirmations. This prevents a previous canceled payment from blocking payment validation on a new order, helping cashiers complete sales reliably.
Original PR description
If you made an order and tried to pay with a payment terminal (like Adyen) then canceled the payment on the terminal. Then leave the order and create a new order, add different products, and try to…
If you made an order and tried to pay with a payment terminal (like Adyen) then canceled the payment on the terminal. Then leave the order and create a new order, add different products, and try to pay again, pay on the terminal, the payment will not be transmitted to the PoS and the order would still be waiting for payment. Steps to reproduce: ------------------ * Create a pos payment method using adyen * Open a PoS session * Create an order with a product * Pay with the adyen payment method * Cancel the payment on the terminal * Leave the order * Create a new order with different products * Try to pay with the adyen payment method * Validate the payment on the terminal > Observation: The payment will not be transmitted to the PoS and the order will still be waiting for payment. Why the fix: ---------------- The issue occurs because the canceled payment line is still considered as a pending payment line. And when the payment will be receiven on the pos it would take the canceled payment line as the pending one. opw-4805704 Forward-Port-Of: odoo/odoo#222325 Forward-Port-Of: odoo/odoo#219054
The email showcase snippet now keeps its intended side-by-side layout when viewed on large screens. This prevents marketing emails from appearing misaligned after they are sent, helping recipients see the design as it appeared in the editor.
Original PR description
Problem: On large screens, the `s_showcase` template shows blocks stacked vertically instead of side-by-side as in the editor. Cause: After commit 10008b32334152ada1a847b091189d1d9d5aa3d3,…
Problem: On large screens, the `s_showcase` template shows blocks stacked vertically instead of side-by-side as in the editor. Cause: After commit 10008b32334152ada1a847b091189d1d9d5aa3d3, `s_showcase` was refactored to fix selection/formatting issues. Mixing relative widths (`col-sm`) with fixed widths (`col-1`) breaks in `convert_inline`, exceeding the 12-column grid. Solution: - Use `Math.floor` when calculating the `colSize` to prevent overflow Before: <img width="1862" height="948" alt="image" src="https://github.com/user-attachments/assets/35d82103-1f84-4754-862d-50ef3481bcb3" /> After: <img width="1847" height="955" alt="image" src="https://github.com/user-attachments/assets/20e1b454-dfc4-4ad0-9e6a-3b38c230d0fd" /> Steps to reproduce: 1. Open a new email marketing. 2. Drop the `s_showcase` snippet. 3. Send a test email. 4. Observe the received template is misaligned compared to the editor. opw-4946126 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222801
This update corrects how Point of Sale and restaurant order actions communicate internally after a recent change. It helps prevent issues in payment, product, and restaurant workflows caused by mismatched call formats.
Original PR description
In a previous commit, some method signatures were changed to use an options object instead of multiple parameters. This commit updates the affected method calls to use the new options object format. Forward-Port-Of: odoo/odoo#222893 Forward-Port-Of: odoo/odoo#222473
The website builder now falls back to the default value when previewing progress bar settings, preventing invalid values from appearing. The progress bar color picker also shows only the relevant choices, making editing clearer for users.
Original PR description
This commit add a fallback to default value during option preview, as it was already the case in the commit. Steps to reproduce: - Drop `s_progress_bar` snippet - Click on it - Empty "Value" field - NaN appears on progress bar during the preview - Default value of BuilderNumberInput is not used Additionally, progress bar color picker was showing theme and gradient tabs.
This fixes an issue where renaming a custom many-to-many field could make it disappear from the system configuration. The change keeps the internal field registry consistent, reducing the risk of broken customizations after field changes.
Original PR description
Since 6b9df655bb4424302b78cdeec8ed65b7d4106396, when renaming a custom many2many field, the field disappears from its model's `_fields` dict. The field is silently discarded after its setup has crashed, because another field using the same relation is found in `registry.many2many_relations`. This "other" field is actually the renamed field under its old name! The fix thus consists in partially invalidating `registry.many2many_relations` before setting up fields. Co-authored-by: abz-odoo opw-4937841
This fixes an error that could occur when a user removed a product from the parts section of a repair order and then changed the customer. Repair teams can now update these orders without hitting a blocking crash, improving reliability in everyday repair workflows.
Original PR description
When User removes the product from parts in repair order and tries to change the partner, A traceback will appear. Steps to reproduce the error: - Install ``repair`` module - Create new repair order > Add a line > Add a product in parts > Save - Remove product from parts > change customer > Save Traceback: ``` AssertionError: precision_rounding must be positive, got 0.0 ``` https://github.com/odoo/odoo/blob/122dece7eeedbf670254aebd2a2d69642b381547/addons/repair/models/repair.py#L319 When user removes the product from parts, ``precision_rounding`` becomes 0.0 Which results in the above traceback. sentry-6650889934 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223483 Forward-Port-Of: odoo/odoo#212577
Website editors can now add, remove, and re-add carousel slides quickly without triggering an error. This makes page editing more reliable and prevents interruptions when working with carousel content.
Original PR description
Before this commit, rapidly adding and removing slides in the Carousel snippet, a traceback occurred under certain conditions. Step to reproduce: 1. Drop a Carousel Snippet on the page. 2. Rapidly `add -> remove -> add` slides with button in editor. 3. Traceback occurs. Cause: - The issue occurred in the `addSlide` function of the `CarouselItemHeaderMiddleButtons` component. When invoking `callOperation`, the `getEditingElement()` function was returning an orphaned child element that was no longer associated with a valid `.carousel` container due to race condition. Solution: - We now resolve the editing element against its closest `.carousel` parent to avoid orphan elements and ensure stable behavior. task-4270369
This fixes an issue where the Website theme settings tab could appear blank for some themes, including Real Estate. Users can now open and adjust theme options without being blocked by hidden rendering errors.
Original PR description
Since website refactor [1],a silent error would occur while rendering the theme tab, leading to nothing being displayed depending of the theme. This was caused by a duplicate key in the `$o-selected-color-palettes-names` scss variable, added by some theme, which would crash the `t-foreach` template loop. Steps to reproduce: - Create a website using theme_real_estate, through the wizard - Enter edit mode - Click on theme tab - Nothing is rendered [1]: https://github.com/odoo/odoo/commit/9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2
Paymob payment processing now handles date formats that vary by country, including dates with timezone details. It also avoids reusing outdated access tokens after credentials change, reducing the risk of payment connection issues.
Original PR description
Previously, we assumed that the format of created_date provided by paymob was the same for all countries. However it seems like for countries other than Egypt a timezone field is added to the date. Therefore we switched to using 'fromisoformat' instead of 'strptime' to avoid specifying the date format if its not consistent throughout the different countries. Also, if an access token is fetched, then it won't be invalidated when new credentials are given and it might result in faulty behavior. Since the expiry of the access token is about 60 mins, then there is no value to storing the access token on the payment provider and can be fetched when needed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix keeps rating feedback popups and chatter messages in sync across portal and website areas. Users see consistent message content and actions when rating or responding, reducing confusion in customer-facing conversations.
Original PR description
portal, portal_rating, rating, website_slides task-4743757 Forward-Port-Of: odoo/odoo#223243 Forward-Port-Of: odoo/odoo#221050
This fixes an issue where editing a website page could accidentally remove a hidden search setting and cause an error when saving. The search form now keeps the selected sorting information intact, improving reliability for website editors.
Original PR description
Problem: In Website, the `order_by` hidden input stores the selected sort order for search. This input can currently be deleted via `oDeleteBackward`, which may break the form behavior. Solution: Make `order_by` input unremovable to ensure form integrity. Steps to reproduce: - Add a "Title" text block - Insert a search element before the text - Delete all the text - Use backspace to delete the header block - Save - > A traceback occurs because the `order_by` input was deleted opw-4863089 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#220107
This update corrects how rounded corners are calculated for inner visual layers in the website editor. It prevents a styling issue caused by an invalid CSS value, helping edited pages display consistently.
Original PR description
Follow-up of [1], introduced a mistake just before the merge. CSS calc does not support `0` without a unit. [1]: https://github.com/odoo/odoo/commit/d0daf3990079477ef7552d769b944b55d9be4366
The IoT printing flow now continues even when the system cannot check an Epson printer's status. This helps avoid failed or blocked print jobs caused by a status-check issue, improving reliability for businesses using IoT-connected printers.
Original PR description
If for some reason, the IoT Box can't query the epson printer status, we should still try to print: an escpos lib issue shouldn't prevent cups from sending its job.
This fixes the website editor so the Color Filter setting appears below the Video option when editing snippets with background videos. It helps users find and use the relevant design controls in the expected order.
Original PR description
[FIX] website: correctly placed the color filter option Steps to reproduce: - Add a "Text-Image" snippet. - Add a background video. -> The "Color Filter" option is misplaced. Since the [website refactoring], the "Color Filter" option is placed over the "Video" option while it should be under it. This commit fixes this problem. Related to task-4367641 [website refactoring]: https://github.com/odoo/odoo/commit/9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2
Creating an application from a recruitment talent pool now sets the correct initial stage when a job is assigned. This ensures the expected acknowledgment email is sent consistently, avoiding missed candidate communications.
Original PR description
### Steps to reproduce: - Create a talent pool - Check the application created under this pool - Set a job position in this application - Notice the email that got sent - Naviagte to the talent pool - Create a new application - Notice the acknowledgment email won't be sent ### Cause: When creating a new application from the talent pool we don't set a stage_id so it will get computed after creating the application so when checking in _track_template it won't exist in changes. https://github.com/odoo/odoo/blob/9ec4e0d3c5f1aaff0b36dc5def1e69b8285c3be1/addons/hr_recruitment/models/hr_applicant.py#L535-L544 ### Fix: When adding a new application through pool we check the stage related to the job we are assigning to the applicant and we set it so it will exist in changes when checking the email template that should be sent. opw-4925221 Forward-Port-Of: odoo/odoo#223287 Forward-Port-Of: odoo/odoo#220367
This update prevents a point of sale test from removing protected products that are needed elsewhere in the system. By archiving products instead of deleting them during the test, automated checks can run more reliably without triggering avoidable errors.
Original PR description
### Before this commit: - The `test_load_pos_demo_data` test case was deleting all products, including special ones like `Gift card`, `default_booking_product`, leading to errors due to constraints on deleting such records. ### After this commit: - The test case now archives existing products instead of deleting them, avoiding these errors. Runbot Errors: 229904 & 229903 Task: 4974081 Forward-Port-Of: odoo/odoo#223364 Forward-Port-Of: odoo/odoo#221317
Outgoing emails now include links for attachments that are stored in cloud storage, not only for files that exceed the email size limit. This prevents customers or vendors from missing important documents when cloud-backed attachments are added to messages.
Original PR description
Before this commit, when sending emails with attachments stored in the cloud, the attachments's links were not included in the email body, as we only included the links for attachments exceeding the max email size. With this commit, we ensure that all attachments stored in the cloud are converted to links in the email body and included in the the email. opw-4717083 Forward-Port-Of: odoo/odoo#208424
This fixes several property field issues so users no longer see unsupported or confusing property separators in field selection, grouping, and server action screens. It also improves property icon alignment and ensures email templates render relational property values correctly.
Original PR description
Bug === When inserting properties in a domain, or in the server action form view, the property separator should not be visible. Improve the alignment of the pencil / drag property icon. Task-4896271 Forward-Port-Of: odoo/odoo#215767
French companies using Point of Sale can now display the self-service invoice QR code on customer receipts as intended. This helps customers request invoices more easily while keeping the backported change limited and stable for this release.
Original PR description
This commit backports parts of https://github.com/odoo/odoo/commit/4fd28add5c22614a4e5a386a440617edefed6d67, which originally was only merged into master, since it's unstable. Here however, we only backport the bare minimum to make the invoice QR code visible on the receipt, while keeping the changes stable. We also backport the test. opw-4981573 Forward-Port-Of: odoo/odoo#221414
This fix prevents images from appearing larger than intended when editing website pages. Image height and width settings are now preserved correctly, improving visual consistency for content editors.
Original PR description
In `initElementForEdition()`, the `height` and `width` attributes of an image were being converted to CSS properties without specifying units, leading to incorrect rendering. This fix ensures the values are suffixed with 'px' when converting, preserving the intended dimensions. Steps to reproduce: 1. In Website, navigate to `/slides` via the Courses tab. 2. Enter edit mode. 3. Notice that the "current rank" image (number 2) appears enlarged due to missing units in the applied styles.
Repair orders now keep kit components when they are added after the order has been confirmed. This prevents parts from disappearing after saving and ensures the repair order remains accurate for technicians and operations teams.
Original PR description
Steps to reproduce the bug: - Create a repair order with any component. - Confirm the order. - Try to add a kit as a component. Problem: After saving, the kit disappears. When a kit is added to a confirmed repair order, its move should be confirmed and therefore exploded. However, the moves created from this kit move are just copies of the original move. Fields with copy=False are not copied, including the repair_id field. In this case, repair_id must be added to link the move to the repair order, so it needs to be set manually. opw-4937817 Forward-Port-Of: odoo/odoo#222998
This fixes invoice list sorting so users can order customer invoices by the Status and Sent columns. It makes it easier for accounting teams to review invoices by payment progress or whether they have been sent to customers.
Original PR description
**Issue** Users were unable to sort invoices by the "Status" and "Sent" columns in the customer invoices list view. **Steps to Reproduce** 1. Go to Accounting > Customers > Invoices 2. Try sorting by the "Status" or "Sent" columns 3. Observe that sorting is not functional for these fields **Root Cause** Both `status_in_payment` and `move_sent_values` are computed (non-stored) fields. Odoo cannot sort by non-stored fields unless a SQL representation is provided using the `_field_to_sql` method. Opw-4976838 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222357
Users can now validate and send completed signed documents even if an uploaded signing certificate is invalid. This prevents a crash caused by bad certificate data and keeps the signing workflow moving after the existing warning is shown.
Original PR description
Currently, an error occurs when a user sign the document and tries to validate and send the completed document. **Steps to reproduce:** - Install the `sign` module. - Go to: `Sign Settings >…
Currently, an error occurs when a user sign the document and tries to validate and send the completed document. **Steps to reproduce:** - Install the `sign` module. - Go to: `Sign Settings > Cryptographic Signature` > Create a 'Signing certificate' and upload any random PDF (Observe: A warning appears `'This certificate could not be loaded. Either the content or the password is erroneous.'`). - In the Sign app, upload any document, drag and drop a `Signature` field, and sign the document. - Click `Validate & Send Completed Document`. **Note:** - [1] Make sure your system has cryptography version `41.0.7 or above`. - Refer to [2] for steps to reproduce. **Error:** `TypeError: expected bytes-like object, not bool` **Root Cause:** At [3], when the certificate is not correctly created, `certificate.pem_certificate` is `False`, which leads to an error. This commit allows validating and sending a signed document, when the certificate is invalid. [1]: https://github.com/odoo/odoo/blob/d730518fa6a1fba3b3edba6f3b65bcc88ed992fe/odoo/tools/pdf/signature.py#L16 [2]: https://drive.google.com/file/d/19fd82TdGzVPRUVW3PDMGEhyaQLTwL41h/view?usp=sharing [3]: https://github.com/odoo/odoo/blob/a6fa3784b20f75490e405e3728d5a335f2104fa0/odoo/tools/pdf/signature.py#L85 sentry-6796501254 Forward-Port-Of: odoo/odoo#222417
This fixes how Slovenian domestic customers without VAT numbers are classified for accounting. Their sales are now kept under domestic accounts instead of being treated as EU sales, helping revenue reporting stay accurate.
Original PR description
Before this PR: - Domestic customers without VAT were incorrectly mapped to EU fiscal position, causing domestic revenue accounts (760000) to be mapped to EU accounts (761000). After this PR: - Added new domestic fiscal position for non-VAT customers to ensure proper account mapping for domestic transactions. Task-4918960 Forward-Port-Of: odoo/odoo#223328 Forward-Port-Of: odoo/odoo#217311
This fix stops the online store page editor from reloading unexpectedly when replacing a product's main image. It makes product page customization smoother and helps avoid interruptions while merchandising products.
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
Purchase orders now recalculate the company total when the order currency is changed. This helps keep purchasing amounts accurate in the company's currency and avoids stale totals after exchange-rate related edits.
Original PR description
**Steps to reproduce:** 1. Create a Purchase Order (PO) with a non-company currency (e.g., EUR if the main currency is USD). 2. Add at least one order line so the "Amount Total" is greater than zero. 3. Change the currency of the PO to a different one and save the record. **Expected behavior:** The `Company Total` field is recomputed using the new currency's exchange rate. **Actual behavior:** The `Company Total` remains unchanged, still showing the value in the original currency. **Fix:** Add `currency_id` to the `@api.depends` decorator of the `_amount_all` compute method. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#220501
When sending an SMS from a selected phone field, Odoo now keeps that field as the source even if its value is invalid, instead of silently switching to the contact's main phone number. This helps users notice and correct the specific phone value they chose, reducing the chance of messages being sent to an unintended number.
Original PR description
If a user picks a specific field to open the composer with and that field is invalid we currently attempt to pick the number from the partner of the record as a fall back. Instead if the user picked a specific field and it happens to be invalid for some reason, they will want to correct it in-situ rather than have it be something completely different. Some similar tests are regrouped. task-4900210 Forward-Port-Of: odoo/odoo#216242
The website events list now uses the visitor's local day when applying the "Today" filter, instead of relying on UTC. This prevents events from appearing on the wrong day or being missed for users in different time zones.
Original PR description
The filters use today in UTC to fetch events in db. The commit fixes this by located today first and then converts it in UTC. related odoo/odoo@bfd55de7c846a0d523e4de4b17020341d8fcfd23 task-4796181 Forward-Port-Of: odoo/odoo#213205
Vehicle imports in the Fleet app no longer fail when the model year is provided as a number in CSV or XLSX files. This prevents import errors and helps users bring vehicle data into Odoo without manual formatting workarounds.
Original PR description
Currently, when users import a CSV or XLSX file into the Fleet app containing the `model_year` field as an integer, an error is raised. **Steps to Reproduce:** 1) Install **Fleet** app(with Demo…
Currently, when users import a CSV or XLSX file into the Fleet app containing the `model_year` field as an integer, an error is raised. **Steps to Reproduce:** 1) Install **Fleet** app(with Demo Data). 2) Open Fleet App and Import [this file](https://docs.google.com/spreadsheets/d/1KJgVTM7KeAVcHR-TQg86gO4in53G7NyR/edit?usp=sharing&ouid=101212513075316114369&rtpof=true&sd=true). 3) Click on Test or Import. **Error:** `UndefinedFunction: operator does not exist: text = integer` **Root Cause:** Since PR https://github.com/odoo/odoo/pull/197440, the `model_year` field was changed from a `char` to a `selection`. The selection values are generated by the `_get_year_selection` method at [1], which returns a list of integers. However, when these integer value is compared at [2], a type mismatch occurs because the expected type is `text`, not `integer`. **Solution:** This fix ensures that `_get_year_selection` returns a list of **strings** instead of `integers`, so that the values match the expected type at [2] [1]- https://github.com/odoo/odoo/blob/4806b08dcfc965cdbd463269be078f8da9f48863/addons/fleet/models/fleet_vehicle.py#L34-L36 [2]- https://github.com/odoo/odoo/blob/4806b08dcfc965cdbd463269be078f8da9f48863/odoo/addons/base/models/ir_fields.py#L451 sentry-**6663249660** Forward-Port-Of: odoo/odoo#221861
This fix prevents hidden conditionally visible website sections from being accidentally restored when users undo unrelated edits. It keeps the website builder history focused on real content changes, making editing behavior more predictable.
Original PR description
With the initial [website builder refactor], the class `o_conditional_invisible` was tracked in the history. This class is added/moved when the user toggles the visibility in the "Invisible Elements" panel of a conditionnaly visible element. Just toggling the visibility does not add a step, so that mutation was added on the next added step (and undone with it). This commit lists `o_conditional_invisible` in the `system_class` so it is not tracked by the history (like `o_snippet_override_invisible`) Steps to reproduce: - Open website builder - Drop a section - On the section, set "Visibility" to "Conditionally" - In the "Invisible Elements", hide the section - Somewhere else, do a change - Undo the change - Bug: the section is shown again (and redo hide it again) [website builder refactor]: 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2 task-4367641
Point of Sale orders that include the same product on multiple separate lines now report delivered quantities accurately. This prevents overstated delivery figures in sales reporting when customers use ship-later fulfillment.
Original PR description
If you made a sale with multiple lines having the same product, the qty_delivered was not correctly computed on the different lines. Steps to reproduce: ------------------- * Activate the ship later…
If you made a sale with multiple lines having the same product, the qty_delivered was not correctly computed on the different lines. Steps to reproduce: ------------------- * Activate the ship later option in the PoS settings * Open PoS * Add any product with a quantity of 5 * Apply a discount of 20% to the line * Click on the same product so that they are added as a second line * Change the quantity of the second line to 3 * Validate the order and use the ship later option * Validate the picking * Go to the sale report and check the qty_delivered for the product > Observation: The qty_delivered is doubled, 16 instead of 8. Why the fix: ------------ The qty_delivered was computed by summing the quantities of all moves for the product, but it did not take into account that the same product could be present in multiple lines of the same order. We now make sure to dispatch the delivered quantity correctly across the different lines of the order, ensuring that the qty_delivered is accurate. opw-4826487 Forward-Port-Of: odoo/odoo#221373
Point of Sale now calculates taxes on negative order lines the same way as the backend. This prevents discrepancies that could create unbalanced accounting entries and improves reliability for refunds or negative sales lines.
Original PR description
Before this commit, when an order contained a negative line, the backend treated it as a refund line while the POS UI did not. This mismatch caused inconsistent tax calculations between the UI and the backend, which could result in unbalanced journal entries. With this commit, the tax calculation logic is aligned between the UI and the backend, ensuring consistency and preventing unbalanced moves. opw-4972314 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222918 Forward-Port-Of: odoo/odoo#222632
Enabling the Newsletter option in Website Settings now also activates the related customized checkout view. This ensures guest shoppers see the newsletter subscription checkbox during checkout, even after the checkout page has been edited.
Original PR description
Reproduction Steps: --------------------------------------------------- To reproduce the issue first we need to create cowed view, follow the steps below: - Ensure that the website and…
Reproduction Steps: --------------------------------------------------- To reproduce the issue first we need to create cowed view, follow the steps below: - Ensure that the website and website_sale_mass_mailing modules are installed. - Navigate to Website > Shop. - Select any product and add it to the cart. - click on Proceed to checkout then checkout. - On the checkout page, you will see the address form. - Click on "Add a new address". - Now "Edit" the website page (e.g., make the City label bold). This will create a cowed view for the address page. Now, follow the final steps to reproduce the actual issue: - Enable the "Newsletter" option from Website Settings. - Log out of the database. - Go to the website shop, add a product to the cart, and proceed to checkout. - On the address page, the subscription checkbox is not visible for a "Guest" user. Root Cause: -------------------------------------------- The subscription checkbox does not appear because the cowed view of the newsletter is not activated. Solution: --------------------------------------- As of SaaS 17.3, a new module `website_sale_mass_mailing` was introduced, which adds the "Newsletter" option in Website Settings. When this option is enabled, the newsletter view is automatically activated. However, the corresponding cowed views are not automatically activated, causing the subscription checkbox to be missing during guest checkout. To fix this, we ensure that the corresponding cowed view is also activated when the "Newsletter" option is enabled. Related Link: https://github.com/odoo/odoo/pull/154604/files OPW-4860002 UPG-2978748 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223255 Forward-Port-Of: odoo/odoo#214989
Fixes an issue where visitors could hit an access error after using livechat across guest and logged-in sessions. The change ensures related livechat conversations are safely linked to the newly created website visitor, improving reliability for website users and support teams.
Original PR description
When a new website.visitor is created while a guest is set in the context, livechat channels of the related guest need to be updated to link the newly created visitor. Before this PR, the update caused an access error because the public user does not have permission to update channel records. Steps to reproduce: - Go to a tracked page (e.g., /contactus) and start a livechat as a guest, then end it. - Log in as a user, go to a tracked page, start a livechat, then end it. - Log out and go to a tracked page -> an access error occurs. This PR uses sudo to allow updating channels, as guests can access their own channels. task-[4891195](https://www.odoo.com/odoo/project/1519/tasks/4891195) Forward-Port-Of: odoo/odoo#218550
A small internal dependency issue was fixed for an electronic invoicing field that had been renamed previously. This reduces the risk of errors for customers who expose or customize the field through Studio, with no expected impact on standard screens.
Original PR description
In previous PR [1], we renamed field `ubl_xml_id` to `ubl_cii_xml_id`, but failed the compute dependencies. It has next to no impact since this field it not in views, but could lead to problems if people add it through Studio. [1]: https://github.com/odoo/odoo/pull/115627/files#diff-5f7f5f6e9c54527b31f7579db7ef63b5b910794e462cd3346e32387900c13efdR12 task-none Forward-Port-Of: odoo/odoo#223259
This fix makes a Mail test target the correct uploaded attachment, preventing a timing issue that caused intermittent failures. It also improves logging and validation robustness so similar issues are easier to diagnose and less likely to disrupt testing.
Original PR description
The `:not(.o-isUploading)` selector was not targetting the correct attachment, it matched the first one rather than the second one. Also improve logs and robustness of model checking to prevent other potential issues. https://runbot.odoo.com/odoo/error/223165
This fix ensures a payment-related test only uses the demo payment provider when the required demo payment module is installed. It prevents false test failures in setups that install only website sales, improving release reliability without changing customer-facing behavior.
Original PR description
Add module installation check before using "demo" as payment provider to generate payment token for payment register test case. Steps to reproduce: 1. Install single module (website_sale). 2. Run test case `TestAccountPaymentRegister.test_register_payment_doesnt_send_email`. You will get ValueError: Invalid field 'demo_simulated_state' on model 'payment.token' build_error-230731 Forward-Port-Of: odoo/odoo#222330
When an automatically detected absence is edited into a normal attendance, it will now be shown as a regular attendance instead of remaining highlighted as an absence. This prevents corrected attendance records from appearing incorrectly flagged, improving clarity for HR users.
Original PR description
### Steps to reproduce: - Run Absence detection cron - Navigate to the attendances got created in list view - Notice all of them are in red color - Modify the check in and check out dates to correct them as normal attendance - Notice the color didn't change in the view and it is still shows as red ### Cause: This is happening because color of the record is dependant on the check out mode, so if it is technical it means it is absence so we give it red color. https://github.com/odoo/odoo/blob/a7a29ed691db4f1607c0d12929c56845681164fa/addons/hr_attendance/models/hr_attendance.py#L84-L89 Also, the check out mode cannot be changed in any way. ### Fix: When updating the check out and check in time we check if the mode is technical we change it to manual. opw-4865524 Forward-Port-Of: odoo/odoo#218177
This update improves the responsiveness of the website builder by avoiding repeated size checks when row labels are redrawn. Users should experience smoother editing with no change to visible behavior.
Original PR description
The goal of this commit is to speed up the rerendering of the BuilderRow component. In BuilderRow, we need to calculate whether a row's label is too long or not. If so, we display a tooltip. To do this, we use the clientWidth function to determine the size required for the label. This function is considered computationally expensive. We will therefore avoid calling it at each onPatch, since the length of the label and the right-hand side do not change in size. 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
Swedish accounting imports now handle SIE4 files that do not include previous-year information instead of crashing when opening balances are imported. The import also retries with an alternate character encoding when needed, helping customers process more supplier or legacy files successfully.
Original PR description
**Issue**: Importing a SIE4 file without previous year information causes a traceback. **Steps to reproduce**: - Go to Accounting > Settings > Import - Import SIE 4 file - Check the box "Import account opening balances" - Select the right xml and observe the traceback **Cause**: The method `_prepare_sie4_opening_balance_move` tries to directly access the previous year: https://github.com/odoo-dev/enterprise/blob/6d4919658650a006c73d4aaf1f500d67723dda0d/l10n_se_sie4_import/wizard/import_wizard.py#L376C9-L376C58 This results in a traceback when the previous year is not present. **Solution**: Make `_prepare_sie4_opening_balance_move` more permissive by falling back to the day before the first day of the current year if the `-1` section is not there. **Additional Notes**: The client file does not support `UTF8` format, retry with the `ISO-8859-1` format in case of `UnicodeDecodeError`. opw-4894495 Forward-Port-Of: odoo/enterprise#89425
Belgian payroll exports now check required work entry codes before generating files. This prevents exports from failing unexpectedly and gives payroll teams clearer guidance to fix missing setup for supported payroll providers.
Original PR description
Before this commit no usererror was raised when the work entry type has no group s code defined which caused the export to fail. This commit adds a check at generation time for the work entry type to have a group s code defined task-4241431 Forward-Port-Of: odoo/enterprise#71454
When scheduling existing shifts from the Planning Gantt view, the pop-up list no longer shows date and resource columns that are not needed in this flow. This keeps the scheduling experience cleaner and avoids confusing duplicate information for users.
Original PR description
Steps to reproduce: - 1. Go to the Planning module. 2. Open the Gantt view. 3. Click on a cell to schedule an existing shift. 4. The date and resource columns are visible in the pop-up list view. Issue: - When scheduling existing shifts from the Gantt view, the date and resource columns were still visible in the pop-up list view. Cause: - The `planning_slots_to_schedule` context flag was removed in commit c3c4f02, this was used to hide the columns. Fix: - Restore the `planning_slots_to_schedule: true` context in the Gantt renderer to ensure the columns are correctly hidden in the list view. task-4922511
Dutch VAT payment instructions now use the Omzetbelastingnummer when it is available, instead of always using the company VAT number. This prevents incorrect payment communication references on tax payment wizards and helps businesses submit payments with the right identifier.
Original PR description
**Steps to reproduce:** - Install Accounting, l10n_nl and l10n_nl_reports_sbr_ob_nummer - Switch to a Dutch company (e.g. NL Company) - In company form, set VAT and Omzetbelastingnummer - Create an…
**Steps to reproduce:** - Install Accounting, l10n_nl and l10n_nl_reports_sbr_ob_nummer - Switch to a Dutch company (e.g. NL Company) - In company form, set VAT and Omzetbelastingnummer - Create an invoice with tax for previous month - Confirm the invoice - Go to "Accounting / Reporting / Statement Reports / Tax Return" - Select previous month - Create "Closing Entry" and post it - On "Miscellaneous Operations" journal in Accounting dashboard, click on "Pay tax: [date]" link - A wizard will appear fot the VAT payment **Issue:** The value of the "Communication" field is incorrect. **Cause:** The "Communication" field is always computed from the VAT of the company. However, when the "Omzetbelastingnummer" field is set, it should be used instead of the VAT. **Solution:** Use the "Omzetbelastingnummer" field to compute the "Communication" of the VAT payment when it is set. This is done through an overridden method because "Omzetbelastingnummer" is defined in an independent module. opw-4836615 Forward-Port-Of: odoo/enterprise#92691 Forward-Port-Of: odoo/enterprise#92407
This update fixes internal call formats used by Point of Sale restaurant and Urban Piper features after a recent technical change. It helps keep related restaurant preparation and ordering flows working reliably without changing the user experience.
Original PR description
In a previous commit, some method signatures were changed to use an options object instead of multiple parameters. This commit updates the affected method calls to use the new options object format. Forward-Port-Of: odoo/enterprise#92332 Forward-Port-Of: odoo/enterprise#92091
The commission plan can no longer be changed on upsell orders when the original subscription order has Freeze Plan enabled. This avoids misleading sales users and keeps displayed commission settings aligned with how commissions are actually calculated.
Original PR description
**Problem:** An inconsistent behavior occurs when a user changes the commission plan while creating an upsell order for a recurring Sales Order (SO). **Steps to reproduce:** 1) Install the…
**Problem:** An inconsistent behavior occurs when a user changes the commission plan while creating an upsell order for a recurring Sales Order (SO). **Steps to reproduce:** 1) Install the Subscriptions and partner_commission modules. 2) Create a subscription SO with a referrer_id and set a recurrence. 3) Enable the Freeze Plan option and create a commission plan from the view 4) Add a rate of 50 and product category as service in the commission rules. 5) In SOL add a subscription product contains recurrence with unit price of 100 6) Confirm the SO → Create Invoice → Confirm → Pay. 7) Go back to the SO and create an upsell for it. 8) Change the commission plan rate to 30 by creating a new plan. 9)Repeat step 4. **Issue:** When you navigate to the referrer record from the SO and open the Purchase Order via the smart button, you will see two Purchase Order lines both showing a value of 50, even though the upsell order had a new commission plan with a rate of 30. **Cause:** When the invoice is marked as paid, a Purchase Order with POL is created using values from the commission plan. For subscription orders, the system intentionally uses the subscription’s original commission plan instead of the updated one. https://github.com/odoo/enterprise/blob/03a5efc04538fce380ec3ea993e7586047fe117e/partner_commission/models/account_move.py#L197-L203 However, the problem is that the commission plan field remains editable in upsell SOs even when the parent SO has Freeze Plan enabled, misleading users into thinking the new commission plan will be applied. **Solution:** Make the commission plan field read-only for upsell SOs when the parent SO has Freeze Plan enabled. opw-4954307 Forward-Port-Of: odoo/enterprise#92217 Forward-Port-Of: odoo/enterprise#92157
The Planning app no longer shows the auto-plan option for shifts that do not yet have a start or end date. This prevents users from triggering an error when working with unscheduled shifts from sales planning.
Original PR description
**Step to reproduce:** 1. Install sale_planning module 2. Create a product (Sales -> Products): - Set Product Type to Service - Enable Plan Services - Assign both a Planning Role and resources. 3.…
**Step to reproduce:**
1. Install sale_planning module
2. Create a product (Sales -> Products):
- Set Product Type to Service
- Enable Plan Services
- Assign both a Planning Role and resources.
3. Create a sales order for this product.
4. Confirm the Sales Order.
5. Click the "To Plan" button.
6. Switch to List View.
7. Open the Unscheduled Shifts (None) section.
8. Try to generate an Auto Plan.
**Issue:**
A traceback is raised during auto-planning when the start_datetime or end_datetime on the planning slot is missing.
`AttributeError: 'bool' object has no attribute 'astimezone'`
**Cause:**
The `auto_plan_ids()` method assumes that shifts have valid start_datetime and end_datetime.
However, for unscheduled shifts, these fields can be empty (i.e., False), causing the error.
https://github.com/odoo/enterprise/blob/42d829ea6e6a98f251cfffc8fb67b5320a5ada12/planning/models/planning.py#L1076-L1077
**Solution:**
we hide the auto-plan button, in case we do not have startdate or enddate
opw-4812509
co-authored by: Ajit Singh (aksi@odoo.com)
Forward-Port-Of: odoo/enterprise#89383The AI fields interface now treats false boolean values as valid, so users no longer see an unnecessary warning. It also hides an internal separator when inserting properties into AI prompts, making prompt setup cleaner and less confusing.
Original PR description
Bug === The `False` value is a valid value for boolean type, and the warning should not be displayed for that type. When inserting properties in an AI prompt, the property separator should not be visible. Task-4896271 Forward-Port-Of: odoo/enterprise#88483
Files added through the email wizard are now correctly included when sending Sign requests. This prevents recipients from receiving emails without the documents users intended to attach, restoring expected email behavior.
Original PR description
Issue: * When users added attachments in the mail wizard (e.g., from the Sign module), the files were saved in the backend but not included in the outgoing email. Steps to Reproduce: 1. Edit a Sign template and click the Send button. 2. In the wizard, click on the Attachments button and select a file. 3. Press Send. 4. The email is sent, but the selected attachment is missing from the Sign request mail. Fix: * Adjusted the logic to correctly include attachments added through the wizard in the final email. Impact: * Users can now successfully send attachments added via the mail wizard. * Restores expected behavior and prevents missing documents in email. task-5002652 Forward-Port-Of: odoo/enterprise#91975
An accounting test was updated so it no longer depends on a fixed year in generated payment references. This prevents avoidable test failures when the test date changes, helping keep validation and release checks stable.
Original PR description
In `test_matching_rules_with_empty_aml_move_name`, the payment `move_id.name` was hard-coded to use the year "25" in the sequence prefix (e.g. MOVE25/00004). This caused ValidationErrors when the mocked posting date in the test environment belonged to a different year, as the sequence mixin enforces alignment between the move date and sequence year. The test now derives the year suffix dynamically from the actual `move_id.date` to ensure it always matches the posting date used in the test context. This makes the test stable regardless of the current (or mocked) date, removing the need for manual adjustments when fiscal years or test setup dates change. build_error-230659 Forward-Port-Of: odoo/enterprise#92080
The Journal Audit report now handles cases where the underlying Journal Report has had all its lines removed. Instead of showing an error, the report safely stops processing, avoiding disruption for accounting users.
Original PR description
Currently, error occurs when user try to open Journal Audit with no lines. Steps to replicate: - Install `accountant`. - Navigate to `Accountant > Configuration > Accounting reports`, search for `Journal Report` and open it. - Under the Lines tab, delete all the records and save. - Open the `Journal Audit` report, and the error will appear. Error: `IndexError: list index out of range` Cause: - An error occurred because the user deleted all the lines from the report, and the code tried to access the first element [1] of those lines (`lines[0]`) which caused the error. Solution: - Added a check if lines are present, if not then returned from the function. [1]: https://github.com/odoo/enterprise/blob/5670a73ef63d313f6c3df2b1ceeec7f7d6cd6a1b/account_reports/models/account_journal_report.py#L167 sentry-6795898305 Forward-Port-Of: odoo/enterprise#91979
The Sign button now disappears once a document has been fully signed from the chatter. This avoids confusion by showing users the correct document status and preventing unnecessary signing attempts.
Original PR description
Before this fix, even after a user signed a document from the chatter and The document was fully signed, and the Sign button was still visible. In this PR, the button is hidden once the document is fully signed.
Fixed an issue that caused WhatsApp marketing automation tests to crash when run more than once for the same setup. This makes campaign testing more reliable and prevents users from being blocked by an error during validation.
Original PR description
Currently an error occurs when trying to run whatsapp marketing automation test more than once. **Steps to replicate:** * Install `marketing_automation_whatsapp` * Setup whatsapp integration *…
Currently an error occurs when trying to run whatsapp marketing automation test more than once. **Steps to replicate:** * Install `marketing_automation_whatsapp` * Setup whatsapp integration * Marketing Automation > New > Start From Scratch > Add a new activity * Select Activity Type as Whatsapp Message and a Whatsapp Template * Launch a Test > Pick a contact > Launch > Run (Do this step twice) **Error:** `ValueError: Expected singleton: marketing.trace(6, 4, 3, 2, 1)` **Cause:** This error occurs because the variable `trace` contains multiple records, but the `process_event` method is being called on the entire recordset. Since `process_event` uses `self.ensure_one()`, it expects exactly one record, and therefore raises an error at [1] when multiple records are passed. **Solution:** * Handle trace records one by one using a loop. [1]: https://github.com/odoo/enterprise/blob/624b18bdb5dff0df4756c4e1d37a696631e57a05/marketing_automation_whatsapp/models/marketing_trace.py#L20 **Sentry-6772553612** Forward-Port-Of: odoo/enterprise#91207
WhatsApp template previews now avoid treating underscores inside links or words as italic formatting. This keeps portal links and other URLs displayed correctly while preserving intended italic formatting when underscores are separated by spaces.
Original PR description
Steps to reproduce: 1. Go to a WhatsApp template, for e.g. Sale Order. 2. Update the sample value for the Portal Link variable to include an underscore. 3. Click on Preview Issue: Due to the current…
Steps to reproduce: 1. Go to a WhatsApp template, for e.g. Sale Order. 2. Update the sample value for the Portal Link variable to include an underscore. 3. Click on Preview Issue: Due to the current regex, we will apply italic to any underscore we find which is not ideal, mostly when we work with URLs that can contain underscores like "acces_token" which we will try to apply italic to it too. Solution: Following the most common logic for italic formatting, we will only apply italic formatting when the underscore is surrounded by whitespace. This is the same way it already behaves in Whatsapp. If we write it like_this_for example, it will not apply italic formatting, but if we write it like this _this_ it will apply italic formatting. So this for example: **"If we write it like_this_for example"** Will be like - before the fix: **"If we write it like<i>this</i>for example"** Will be like - after the fix: **"If we write it like_this_for example"** opw-4720017 Forward-Port-Of: odoo/enterprise#91217
Non-recurring products sold through subscription upsell orders are now included in the Sales Analysis Report. This gives teams more complete delivered quantity and revenue figures, reducing the risk of underreporting upsell performance.
Original PR description
Problem: The non-recurring products added through upsell Sales Orders are not included in the Sales Analysis Report. This results in missing sales data for those products, leading to inaccurate…
Problem:
The non-recurring products added through upsell Sales Orders are not included in the Sales Analysis Report. This results in missing sales data for those products, leading to inaccurate reporting.
Purpose:
To ensure that non-recurring products added through upsell Sales Orders are correctly included in the Sales Analysis Report (report_all_channels_sales_action). This fix updates the report's domain filter to include upsell orders when the product is not recurring, resolving the issue of missing sales data for such products.
Steps to reproduce the bug:
1. Create a Sales Order (SO):
Add two products to the order:
- One recurring product (e.g., a subscription-based product with a recurring billing policy).
- One non-recurring (standard) product.
2. Confirm the SO
3. Generate an Invoice for the confirmed SO.
4. Validate the Invoice and deliver the non-recurring product (process the delivery order fully).
5. Create an Upsell Sales Order:
- From the original SO, create a new upsell SO.
- Add the same non-recurring product again.
6. Navigate to the Non-Recurring Product Page:
- Open the Product form for the non-recurring item.
- Click on the "Sold" smart button (shows delivered/sold quantities in the past 365 days).
- This opens the Sales Analysis Report (report_all_channels_sales_action) filtered by this product.
Issue:
The upsell Sales Order is not included in the Sales Analysis Report for the non-recurring product. As a result, the delivered quantity or revenue from upsell SOs is missing from the report for non-recurring products.
opw-4940977
Forward-Port-Of: odoo/enterprise#92559The Swiss payroll wage type form no longer shows a message panel that was left behind after related messaging support was removed. This prevents users from seeing a non-working area in the payroll setup screen and keeps the form clearer.
Original PR description
After mail thread was removed from the model, the chatter is still present in the view and should be removed
Fixed an issue that caused an error when users grouped commission records in Sales. This keeps commission reporting usable and prevents interruptions when analyzing commission data.
Original PR description
When user tries to group by in commission, a traceback will appear. Steps to reproduce the error: - Install ``sale_commission`` module - Go to Sales > Commissions > My Commissions > Group by with any…
When user tries to group by in commission, a traceback will appear. Steps to reproduce the error: - Install ``sale_commission`` module - Go to Sales > Commissions > My Commissions > Group by with any field Traceback: ``` TypeError: strptime() argument 1 must be str, not datetime.date ``` After this [commit,](https://github.com/odoo/odoo/commit/26c37c9c070107f8bd753cb8a6d8343384fdd7bf) When grouping, the ``web_read_group`` method is invoked, which internally calls ``optimize() → _optimize() → _optimize_type_date() → _value_to_date()``. The ``_value_to_date()`` method returns a ``datetime.date`` object from below lines for default filters and group by. https://github.com/odoo/odoo/blob/b42d8ebee73fbf8a8eac0222ae9bcaee3fa33c98/odoo/orm/domains.py#L1417-L1420 https://github.com/odoo/enterprise/blob/3b2556d174cc2b5e3bfe9e72f1f02fea87310653/sale_commission/report/commission_report.py#L31-L38 So, In the domain, a ``datetime.date`` is passed, but ``strptime()`` expects a ``string`` at the above line, leading to a traceback. Sentry-6785019405
The Planning app now handles invalid shift template hours more gracefully. If a user enters an end or start hour outside the allowed range, they receive a validation message instead of triggering a system error.
Original PR description
Currently, an error occurs when entering an invalid end hour in the shift template. Steps to Reproduce: - Install the `planning` module. - Go to `Shift Templates`. - Create a new `shift template` and…
Currently, an error occurs when entering an invalid end hour in the shift template. Steps to Reproduce: - Install the `planning` module. - Go to `Shift Templates`. - Create a new `shift template` and enter an `invalid end hour (greater than or equal to 24)` > `save`. `ValueError: hour must be in 0..23` This error occurs after [this commit](https://github.com/odoo/enterprise/commit/a0bb61f5871fe02a0a32691f33dabfb06c9d2ce2), which added the _get_name method to generate the display name without validating the data.when a user enter invalid value in the end hour while creating or editing shift template. The compute method is then triggered, which attempts to generate the display name [1] based on the formatted time. During the formatting of the end time, the hour value is invalid for the time function,and raise the error [2]. This commit ensures that if the start hour or end hour is invalid, it raises a validation error, similar to [this commit](https://github.com/odoo/enterprise/pull/67580/commits/fa566f9de1b8f75510cbc01837fb3ff4764eccdf). [1]- https://github.com/odoo/enterprise/blob/3009d64c72ef3f4e6bae64ddb9e24f48a4f778a5/planning/models/planning_template.py#L54 [2]- https://github.com/odoo/enterprise/blob/3009d64c72ef3f4e6bae64ddb9e24f48a4f778a5/planning/models/planning_template.py#L74-L78 sentry-6792658060
Batch payment validation now avoids posting an incorrect message saying a payment was removed when it actually remains in the batch. This keeps payment history clearer and helps users trust the audit trail during payment processing.
Original PR description
When validating a batch that includes payments in process (e.g., without journal entries), Odoo incorrectly logs that the payment was removed from the batch, even though it remains. This commit fixes the chatter message by not possessing the write method of the account_payment if batch_payment_id not in vals. task-5011672 Forward-Port-Of: odoo/enterprise#92197
Fixed an issue where reconciling multiple batch payments for different installments of the same bill could fail after the first installment was already reconciled. The system now only uses unpaid installment lines during reconciliation, helping accountants process split vendor payments without manual workarounds.
Original PR description
**Steps to reproduce:** - Install accountant - Go to "Accounting / Configuration / Invoicing / Payment Terms" - Create a payment term having at least 2 installments (e.g. 20%-80%) - Create a bill: *…
**Steps to reproduce:** - Install accountant - Go to "Accounting / Configuration / Invoicing / Payment Terms" - Create a payment term having at least 2 installments (e.g. 20%-80%) - Create a bill: * Vendor: [any] * Payment terms: [the created payment term] * Amount: 1000 - Confirm the bill - Pay the first installment from the bill (i.e. 200) - Go to "Accounting / Vendors / Payments" - Select the payment and create a batch - Validate the batch payment - From Accounting dashboard, go to Bank journal - Create a statement: * Partner: [None] * Amount: -200 - Reconcile the statement with the batch payment - From the bill, pay the second installment (i.e. 800) - Go to "Accounting / Vendors / Payments" - Select the payment and create a batch - Validate the batch payment - From Accounting dashboard, go to Bank journal - Create a statement: * Partner: [None] * Amount: -800 - Reconcile the statement with the batch payment **Issue:** The following UserError is raised: "You are trying to reconcile some entries that are already reconciled." **Cause:** When reconciling a batch payment, all the payment term lines from the invoices/bills linked to the payment are used. However, in this case, when the first batch payment has been reconciled, the first payment term line of the bill (linked to the first installment) has been reconciled. It should not be reused when reconciling the second batch payment. **Solution:** Exclude reconciled payment term lines when reconciling a batch payment. opw-4830185 Forward-Port-Of: odoo/enterprise#92524 Forward-Port-Of: odoo/enterprise#91367
Users working with Kenyan localization can now search products by KRA item code without the product screen failing. This fixes a broken search option that previously caused backend errors and no visible result in the interface.
Original PR description
This commit odoo/enterprise@c17ebfc7cdf2b218945280e6e3bd09f2b9ee8adc added a [searchview](https://github.com/odoo/enterprise/blob/17.0/l10n_ke_edi_oscu/views/product_views.xml#L74-L84) for `l10n_ke_item_code` but it never worked. as `l10n_ke_item_code` in `product.template` is non-stored field, we generally get error in console about it. fast forward to newer version e.g. saas-18.3, searching on non-stored fields raises traceback on frontend. Step to reproduce: - install L10N_ke and sale_management - switch to kenya company - go to product in sales app - type something in search bar and select 'kra item code' from autocomplete Observation: - nothing happens on frontend - on backend we receive a error `ERROR odoo.osv.expression: Non-stored field product.template.l10n_ke_item_code cannot be searched.` Fix: - we introduce a search method for l10n_ke_item_code field opw-4985176 Forward-Port-Of: odoo/enterprise#91526