Daily updates from Odoo
Tuesday, October 28, 2025
33 changes · 19.0
Enhancements to existing features
This update adds end-of-day balance reporting and refund support for Six payment terminals in Point of Sale. It also improves transaction speed, receipt handling, and payment details so store teams get a smoother checkout and closing process.
Original PR description
Based on the feedback received from our partners we are missing some features in our Six terminal integration. This PR adds them 1. Send balance command to print end-of-day report 2. Adapt the code to reduce the sleep delay after each transaction 3. Refunds/payment reversals for Six + it also adds some minor code improvements like a) Card brand is now saved in pos payments instead of the card number b) Card number is still being sent to PoS and while not stored in v17 will be stored from v18 c) The code of ctypes_terminal_driver and Six Driver was improved to reuse the buffer size and improve the buffer usage d) Fixes the receipt size for the Six terminals e) updates the Six C libraries used to the latest version to get all the newest fixes Related C PR: https://github.com/odoo/worldline-lib/pull/9 Forward-Port-Of: odoo/enterprise#98132 Forward-Port-Of: odoo/enterprise#96748
The HTML editor now handles format removal more consistently for headings and other block text. This helps users clean up styled text while preserving the intended base typography, reducing confusing formatting behavior when editing website or document content.
Original PR description
Description of the issue this PR addresses: Current behavior before PR: Styles applied via typography classes such as `display-1-fs`, `display-2-fs`, etc. could not be removed from block elements. eg: `<h1 class="display-1-fs">t[es]t</h1>`. Desired behavior after PR is merged: - HTML tags (`<p>`, `<h1>`, etc.) represent the base typography. - Typography classes (display-*) should be treated like equivalent HTML tags, not as removable styles. - Only display classes (*-fs) are considered for format removal. - When removing format, the editor now restores the font style of the underlying HTML tag. eg: `<h1 class="display-1-fs">t<span class="h1">[es]</span>t</h1>` task-4981275 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The HTML editor now handles inline code formatting more reliably, including wrapping selected text when the backtick key is pressed and supporting empty inline code blocks. This prevents cursor jumps and makes navigation around code-formatted text smoother for users editing content.
Original PR description
**Purpose of this PR:** This PR includes multiple fixes and improvements related to typing and navigating around inline code elements. **Current behavior before this PR:** - Because of the change…
**Purpose of this PR:**
This PR includes multiple fixes and improvements related to typing and navigating around inline code elements.
**Current behavior before this PR:**
- Because of the change made in commit [1], the selection was not set until two backticks were detected. As a result, inserting a single backtick caused the cursor position to change unexpectedly.
- Typing two backticks (``) without any text between them did not properly create an inline code element.
Desired behavior after this PR is merged:
- The text node is merged with its siblings only when two backtick are detected, so no DOM changes occur with a single backtick, and the selection no longer needs to be updated in that case.
- Now, a zws is added as a sibling of the inline code element to ensure proper navigation outside the code element.
- Typing two backticks with nothing in between now correctly creates an empty inline code element.
- Wrap the selected text in a inline code element when the '`' key is pressed.
- Replaced ZWS with feffs around and inside inline code elements.
This improves:
- feffs are now added on editor initialization (like links) and removed during cleanForSave.
- Arrow key navigation no longer skips characters at code boundaries.
- Empty inline code elements can properly hold the cursor(via mouse or arrow keys).
task: 4585706
[1]: https://github.com/odoo/odoo/commit/f792acf0bc66fb77e25bf8a0753c6a2f4284f0e8Turkish Nilvera e-invoices now accept valid invoice numbering formats beyond a single separator style. The system also checks invoice names before sending, reducing failed submissions caused by XML generation errors.
Original PR description
Before this commit:
- When sending an e-invoice through Nilvera, the invoice name used a hardcoded `.split('/')`, assuming `/` the only valid separator for fetching prefix, year and sequence.
- Invoice name was not validated, which could raise errors during XML generation
After this commit:
- The logic now supports various valid invoice name formats rather than relying only on `/` as a separator.
- Invoice name is validated before sending the e-invoice through Nilvera to ensure they comply with the GIB format, to prevent XML generation errors.
task-5117359The HR contract timeline now shows a contract line beneath the version timeline, making it easier to understand how contract details relate to each version. This improves readability for HR users reviewing employee contract history.
Resolved issues and error corrections
This fixes the Brazilian AvaTax product error workflow so users are shown the tailored product list again instead of a generic product list. The restored view includes Brazil-specific tax fields, inline editing, and an easy path to open product details, helping users resolve tax setup issues correctly.
Original PR description
The actionable_errors widget was changed to ignore views if a view_mode key is present in the action [1]. It caused the standard product.product list view to pop up, which doesn't work in this case. The custom views have the relevant Brazilian fields (SPED type etc), can be edited inline, and have a "View" button allowing the user to go to the product form view. The standard view has none of these. [1] odoo/odoo@3bd833c73ea654d8558e3d9701ad41e4d75ddd6 opw-5154766 Forward-Port-Of: odoo/enterprise#98012
Down payment invoices for subscription upsell orders now show the amount actually paid instead of incorrectly displaying zero. This helps customers and staff see accurate billing information when partial online payments are used.
Original PR description
Version- 17.0 ### Issue: - When an upsell order is partially paid (e.g., 10% of the original amount), the generated downpayment invoice incorrectly displayed an invoiced amount of 0. ### Steps to reproduce: - Make an Upsell order of subscription. - Update the condition of Online Payment from 100% to 10% (in this case). - Make the payment of 10% from portal view. - The invoice amount will be shown as $0. ### Fix: - Updated `_get_subscription_qty_to_invoice` to correctly determine the invoiced quantity and amount for downpayment invoices on upsell orders. ### Impact: - The downpayment invoices for upsell orders now correctly reflect the actual invoiced amount. Forward-Port-Of: odoo/enterprise#97571 Forward-Port-Of: odoo/enterprise#96719
This fixes an issue where validating a partial barcode transfer into another package could incorrectly fail with a missing lot or serial number error. Businesses using lot-valued inventory can now split packaged quantities more reliably without being blocked during warehouse validation.
Original PR description
**Problem:** With a valued by lot/SN product, assigning a partial barcode move line to a new package will trigger a lot error when validating even if there is a lot on the line. **Steps to…
**Problem:** With a valued by lot/SN product, assigning a partial barcode move line to a new package will trigger a lot error when validating even if there is a lot on the line. **Steps to reproduce:** - Create product tracked by lot and valued by lot/SN. - Set on on hand quantity of 100 in stock with a package that you create and a lot that you create. - Create an internal transfer for 100 of this product. - Mark it as to do. - Open it in barcode. - Scan stock. - Scan the package. - Edit the line to quantity of 50. - Scan any other empty package already existing to set it as the delivery package. - Validate. - On the incomplete transfer widget, also click on validate. **Current behavior:** An error 'Lot/Serial number is mandatory for product valuated by lot' is triggered even though there is a lot on the line. **Cause of the issue:** When _assignEmptyPackage() is called to assign the new package, it calls shouldsplitline() which returns true because line.qty_done is smaller thant line.reserved_uom_qty https://github.com/odoo/enterprise/blob/931779b845291e1dc7efdea91d91bdfa5ab703d6/stock_barcode/static/src/models/barcode_picking_model.js#L949-52 Therefore, splitLine() is called and a new line is created with no package and no lot. Then, when we validate, _action_done() is called on the move which calls _action_done() on the move lines. https://github.com/odoo/odoo/blob/30189db8a47e69038242a68706cfdfe6c152e779/addons/stock/models/stock_move.py#L2065 In the stock_account override, the error is raised for the line newly created because it has no lot_id and no lot_name. https://github.com/odoo/odoo/blob/30189db8a47e69038242a68706cfdfe6c152e779/addons/stock_account/models/stock_move_line.py#L90-L91 opw-5028008 Forward-Port-Of: odoo/odoo#233129 Forward-Port-Of: odoo/odoo#231482
Users can now open an AI chat from the AI app even when several chats with the same AI agent are already open. This prevents an error that interrupted the workflow and makes the AI app behavior consistent with opening chats from the system tray.
Original PR description
Currently an error occurs when user tries to open an ai chat through the ai app while having a few ai chats open from the same ai agent. **Steps to replicate:** - Install `ai_app` and open AI app. -…
Currently an error occurs when user tries to open an ai chat through the ai app while having a few ai chats open from the same ai agent. **Steps to replicate:** - Install `ai_app` and open AI app. - Click on the AI icon in the system tray, open two chat windows. - Click on the `Ask AI` kanban card, the error will occur. **Error:** `ValueError: Expected singleton: discuss.channel(69, 70)` **Cause:** - Error occurs because there are already a few discuss channels active that are linked to the same ai agent, and the search query [1] returns multiple ids and ultimately multiple ids will be received at the the line [2] and cause the singleton error. **Solution:** - Ensure that only the first matching discuss channel is returned for a given AI agent when multiple channels exist. - Changed the method `action_ask_ai()` to always open a new ai chat, similar to when we click the ai icon in systray to maintain consistency. [1]: https://github.com/odoo/enterprise/blob/6b1c54d8a1c3b27e72a17d9984e632cc4afd8b64/ai/models/ai_agent.py#L686-L689 [2]: https://github.com/odoo/enterprise/blob/6b1c54d8a1c3b27e72a17d9984e632cc4afd8b64/ai/models/ai_agent.py#L432 **sentry-6849936794**
The point of sale iMin cashbox now uses the correct connection status before opening. This restores cash drawer opening for businesses using iMin hardware and prevents failed cashbox actions at checkout.
Original PR description
Explanation: openCashbox() is calling this.connected to check if iMin is connected. However the variable is changed to isConnected in the previous PR. Therefore it will always return null.
Creating invoices from multiple sales orders now keeps orders with different fiscal positions on separate draft invoices. This prevents incorrect tax or account calculations when orders require different fiscal treatment.
Original PR description
Problem: When a user selects multiple sale orders from the list view to create invoices, if the selected orders have different fiscal positions, they are all incorrectly merged into a single draft…
Problem: When a user selects multiple sale orders from the list view to create invoices, if the selected orders have different fiscal positions, they are all incorrectly merged into a single draft invoice. An invoice can only have one fiscal position. This merging causes unexpected behavior, as the accounts and taxes are computed based on the single (and potentially incorrect) fiscal position of the final invoice, rather than the respective fiscal positions of the originating SOs. Solution: This commit modifies the 'Create Invoices' action to group the selected sale orders by their `fiscal_position_id`. It will now create as many separate draft invoices as there are unique fiscal positions among the selected orders. task: 5188965 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#233119 Forward-Port-Of: odoo/odoo#232821
This fixes a problem where Odoo's automatic invoice sending could stop when a Spanish VeriFactu credit note was linked to an invoice without VeriFactu data. The process now skips affected records and reports them properly, so other invoices can still be sent automatically.
Original PR description
### Steps to reproduce: - Install l10n_es_edi_verifactu and switch too Spanish company - Create an invoice, add a nonzero product and Confirm - Select "Reverse" to create a credit note - Confirm the…
### Steps to reproduce: - Install l10n_es_edi_verifactu and switch too Spanish company - Create an invoice, add a nonzero product and Confirm - Select "Reverse" to create a credit note - Confirm the credit note - Select Send (or Send and Print), deselect everything except VeriFactu and email, then select Confirm - An error appears that takes the user to the failed record - Navigate to Accounting > Customers > Credit Notes - Select the credit note created and at least one other credit note, then select "Send" - Navigate to Settings > Technical > Scheduled Actions - Click into the "Send Invoices Automatically" record, then select "Run Manually" - Version 18.3: the scheduled action fails, no error message appears. The traceback can be seen in the logs - Version 18.0 and lower: The scheduled action fails, but an error message does appear ### Cause: When trying to generate the verifactu documents for a credit note whose invoice has no verifactu document, a `RedirectError` is raised. This means the scheduled action "Send invoices automatically" is cancelled if only one credit note as this issue: no invoices are sent. ### Solution: The usual way to handle user errors with the scheduled action is to append the key 'error' in the dictionnary `send_and_print_values`. This way a message is displayed when running the scheduled action mentioning the moves in error. So we check do the checks and remove the invalid moves before calling `_l10n_es_edi_verifactu_mark_for_next_batch()`. Like this we can change the key "error" in the dictionnary and stop the document generation there. We also extend `_hook_if_errors()` to raise a `RedirectWarning` if it's one of the errors related to Verifactu that we removed. opw-5091347 Forward-Port-Of: odoo/odoo#232763 Forward-Port-Of: odoo/odoo#230762
This fixes event registrations where Google's verification could expire if someone took more than two minutes to complete a long form. Attendees can now finish longer sign-up forms without being blocked by an expired verification check.
Original PR description
Description of the issue/feature this PR addresses: This PR aims to fix the timeout issue coming up for google recaptcha when the event registration form filing exceeds 2 mins(timeout value for google recaptcha tokens) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes inventory valuation for average-cost products when stock is scrapped using a packaging unit such as a pack of 6. Reports now subtract the correct quantity and value, helping businesses avoid overstated inventory values and inaccurate stock accounting.
Original PR description
**Steps to reproduce:** - Create a storable product. - Set the category as avco. - Set the cost to 10 - Set an on hand quantity of 10 - In the Sales tab, add 'pack of 6' to the packagings - Create a new scrap - Scrap 1 pack of 6 of this product - Open reporting/stock and search your product **Current behavior:** The value is 90 **Expected behavior:** It should be 40 **Cause of the issue:** get_valued_qty does not take into account the uom opw-5160608
Opening the invoicing dashboard no longer fails when Stripe expense card issuing is enabled but the company only has unsupported currencies active. The system now avoids creating or selecting Stripe issuing journals unless a valid supported currency is available, reducing setup disruptions for localized companies.
Original PR description
Currently, an error occurs when a user opens the invoicing dashboard after activating the `hr_expense_stripe` module for Stripe card issuing with only unsupported currencies active. **Steps to…
Currently, an error occurs when a user opens the invoicing dashboard after activating the `hr_expense_stripe` module for Stripe card issuing with only unsupported currencies active. **Steps to replicate:** * Install `account` without demo * Set Company currency to INR and deactivate USD in currencies. * Install `hr_expense_stripe` > Open Invoicing you will get the error. `ValueError: Expected singleton: res.currency()` **RootCause:** * When `hr_expense_stripe` is installed, the compute method [1] checks for supported currencies and defaults to USD if none are found. But since USD is often inactive by default in localized online databases, `stripe_currency_id` ends up empty . * Which causes [2] to pass an empty `stripe_currency_id` to [3], which expects at least one record, leading to the error. **Solution:** * Avoid creation of stripe issuance journal during installation when currency is not supported. * Add a constraint to check if stripe currency is valid for creating stripe issuance journal. * prevent creation and selection of journal for stripe issuing from settings. * [Reference Images](https://www.notion.so/Changes-in-Stripe-issuing-unsupported-vs-supported-2856722d865e803e8da1ece29cce7582?source=copy_link) for before and after functionality [1]: https://github.com/odoo/enterprise/blob/2ea15cc9c7c5f114b3786b256c64e269b3e3a313/hr_expense_stripe/models/res_company.py#L72 [2]: https://github.com/odoo/enterprise/blob/2ea15cc9c7c5f114b3786b256c64e269b3e3a313/hr_expense_stripe/models/account_journal.py#L52 [3]: https://github.com/odoo/odoo/blob/98bae80f57733162c67593539ef47dfd0c6d8797/odoo/addons/base/models/res_currency.py#L205 sentry-6916946380
Website builder sections using the "Repeat pattern" background option now show the image repeatedly as intended. This prevents visual layout issues on websites and email designs that rely on patterned backgrounds.
Original PR description
__Current behavior before commit:__ When setting the background image position to "Repeat pattern" in the website builder, the background image does not repeat as expected. This is due to conflicting…
__Current behavior before commit:__ When setting the background image position to "Repeat pattern" in the website builder, the background image does not repeat as expected. This is due to conflicting CSS rules where `background-repeat: no-repeat` from [`html_builder/static/src/scss/background.scss`][1] overrides the intended `background-repeat: repeat` from `html_editor.common.scss`. __Description of the fix:__ 1. Added `!important` to `background-repeat: repeat` to ensure the repeat pattern takes precedence over other styles 2. Removed duplicate and conflicting background styles from `mass_mailing/theme_default.scss` since these are already properly defined in `html_editor.common.scss` 3. Updated the test in `parallax_option.test.js` to verify `background-repeat: repeat` style is actually applied __Steps to reproduce:__ 1. Open website builder 2. Add a section with a background image 3. Change image position to "Repeat pattern" 4. Bug: background doesn't repeat [1]: https://github.com/odoo/odoo/blob/f0a34badefd432e9c2ab36acaf018d20d0e342fe/addons/html_builder/static/src/scss/background.scss#L25 task-5145343
This fixes cases where edit or write restrictions on related record fields were ignored, allowing users to modify data when the field configuration intended to block it. Businesses can rely more consistently on form settings to prevent unintended changes in related lists.
Original PR description
Before this commit, specifying the `edit` or `write` crud options on an x2many field didn't work. The `edit` action was overruled by the view mode (true iff the record datapoint is in edition), and the `write` action wasn't correctly honored in x2many. This commit ensures the `write` action is taken into account. In master, we'll rationalize this to merge `edit` and `write` in a single action. Task~5160367 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
Bank reconciliation rules using “Not Contains” on labels now match correctly even when some transaction text fields are empty. This helps accounting teams rely on automated reconciliation rules more consistently and reduces missed matches.
Original PR description
Currently bank reconciliation model match only the label type “Contains” The “not contain” type is not working Steps to reproduce: - Open Accounting Dashboard - Access Bank journal reconciliation models (3dots > Models) - Open a [Model] and set: - Label "Not Contains" "Test" - Add a Bank Statement with any label Issue: [Model] won't match Analysis: This occurs because in case the payment_ref or transaction_details contains a NULL value the ILIKE operations will evaluate to NULL, not TRUE or FALSE. Any other comparison involving NULL value will result in NULL and the whole condition will fail opw-5065006 [Task link](https://www.odoo.com/odoo/project/49/tasks/5065006) Forward-Port-Of: odoo/enterprise#97745
Repair service products that are published for sale are now correctly shown in the website shop. This prevents customers from missing eligible repair-related services when browsing or searching online.
Original PR description
Steps to reproduce: ------------------------- 1. Install repair and website_sale modules 2. Create a product that is the service type 3. Configure a product to create a repair order when the product…
Steps to reproduce: ------------------------- 1. Install repair and website_sale modules 2. Create a product that is the service type 3. Configure a product to create a repair order when the product is ordered 4. Publish the product from the Sales tab 5. Open the website without being signed in 6. Search for that product Observation: ------------------------- The product is not visible on the website shop. Issue: ------------------------- The method `_get_saleable_tracking_types(self)` is used to determine which product service tracking types are considered saleable on the website. However, this method was not defined for repair products, causing them to be excluded from the domain used to fetch saleable products. https://github.com/odoo/odoo/blob/b0203ae02d472bd7522bc21971f0e659766eaffe/addons/website_sale/models/website.py#L301-L308 Solution: ------------------------- Define the `_get_saleable_tracking_types(self)` method for repair products so they are properly included in website listings. opw-5102204 Forward-Port-Of: odoo/odoo#232154 Forward-Port-Of: odoo/odoo#231000
This fix prevents Odoo from creating many duplicate stock routes when a new warehouse is added after an existing global route has been renamed. It keeps warehouse setup cleaner and avoids confusion or extra maintenance for inventory teams.
Original PR description
In _find_or_create_global_route, use the asked 'route_name' instead of the potentially modified name of `data_route`. This ensures that if '_find_or_create_global_route' is called with the exact same values a new route will not be re-created. https://github.com/user-attachments/assets/815adf60-aa2d-4699-a79d-f9ad9607cbea ## How to reproduce (in runbot 17.0): - Enable "Multi-steps Routes" - Unarchive route "Replenish on Order (MTO)", change the name, set company to "My company (San Francisco)" - Go to "My Company (Chicago)" - Create new Warehouse => Check all the routes: ~100 MTO routes with the modified name have been created. OPW-5149842 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232829 Forward-Port-Of: odoo/odoo#232613
This fix prevents an error when users change the linked sales order from a delivery order. It ensures delivery records stay correctly connected to sales orders, avoiding interruptions during order fulfillment workflows.
Original PR description
Currently, an error occurs when user updates the sale order in the delivery picking. Steps to Reproduce: - Install the `sale_stock` and `sale_management` modules. - Create a `sale order` and…
Currently, an error occurs when user updates the sale order in the delivery picking. Steps to Reproduce: - Install the `sale_stock` and `sale_management` modules. - Create a `sale order` and `confirm` it. - Click the `Delivery button` on top of the order. - In the `Additional Info` tab of the sale order, select any order in `sale order` field and `save`. `psycopg2.ProgrammingError: can't adapt type 'sale.order'` `KeyError: <Command.LINK: 4>` This error occur after [this commit] where, after creating sale order, navigating to its delivery picking, and selecting the same or a different order, an invalid link caused the error[1]. This commit ensures that the sale order is linked correctly to the delivery picking. [this commit]: https://github.com/odoo/odoo/commit/2713876dbc70d3984e584a9037a2206dcda4e84a#diff-2b9de2e50ff5e1dc0362b825bac2b07623770fb3275b3257ef972f255f3ccb8bR172-R173 [1]- https://github.com/odoo/odoo/blob/d484516bcae1beb767d90d20e1ab294f1e9ae8a9/addons/sale_stock/models/stock.py#L173 sentry-6921046230 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users now receive a clear warning when trying to send batch invoices while the required scheduled process is disabled. This prevents silent failures and directs administrators to the right configuration so invoice sending can be restored quickly.
Original PR description
This commit raises a RedirectWarning to the cron configuration to inform the user that the batch invoice cron must be enabled. Batch invoices cannot be sent if cron is disabled. task-5122707 Current behavior before PR: If batch invoice send is called and cron is disabled, then it will silently fail and not send. Desired behavior after PR is merged: If batch invoice send is called and cron is disabled, then it will raise a RedirectWarning to the cron configuration. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#229318
UPS shipping labels can now be generated even when the sender or shipper VAT number is not provided. This prevents production shipments from being blocked by a UPS error caused by sending blank tax ID values.
Original PR description
Only in production mode, if the sender or the shipper's VAT was not set, the UPS answer would be an error, preventing the label generation altogether. This is because we send an empty string if the VAT was not set, and UPS couldn't process it. Forward-Port-Of: odoo/enterprise#98227
Invoices sent together to Spain’s TicketBAI are now numbered in the correct posting order, from oldest to newest. This helps keep the legally required invoice chain consistent and avoids reversed numbering when users submit multiple invoices from a list.
Original PR description
Steps to reproduce: 1) Install l10n_es and l10n_es_edi_tbai. 2) Create a Spanish contact with a valid address and NIF. 3) Create several customer invoices and confirm (post) them. 4) From the list…
Steps to reproduce: 1) Install l10n_es and l10n_es_edi_tbai. 2) Create a Spanish contact with a valid address and NIF. 3) Create several customer invoices and confirm (post) them. 4) From the list view, select them and send to TicketBAI. 5) The TicketBAI “chain index” is inverted: the newest invoice gets the smallest index and the oldest gets the largest. The first invoice in the legal/chronological sequence is not index 1. Current behavior: - When sending multiple invoices at once, the processing loop uses the batch order as-is, which (from the list view) often arrives in reverse chronological order. The chain index is assigned incrementally based on that order, yielding an inverted chain (newest=1, oldest=N). Expected behavior: - The TicketBAI chain index must follow issuance/confirmation chronology: the oldest posted invoice in the batch is index 1, then 2, … up to the newest. Technical reason: - `_call_web_service_before_invoice_pdf_render` iterates `invoices_data.items()` without an explicit ordering by confirmation (posting) date. Depending on how the selection is built, items are processed newest-first, so the computed `chain_index` is reversed. Solution: - Sort the invoices before sending by posting date (`move.date`) ascending, with fallbacks to `invoice_date` and `create_date`, and a deterministic tiebreaker by `id`. Process sequentially after sorting and keep the per-invoice commit. opw-[5072667](https://www.odoo.com/odoo/my-tasks/5072667) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233105 Forward-Port-Of: odoo/odoo#229736
This fix prevents duplicate or incorrect work entry handling when employee attendance spans multiple days or uses different calendar types. It also stabilizes related tests and updates performance expectations so payroll and attendance calculations remain reliable.
Original PR description
- removed the logic for handling attendance spanning multiple days from `_create_work_entries` in `hr_work_entry_attendance` because it's already handled correctly in `_generate_work_entries_postprocess` - added `freeze_time` to `test_attendance_spanning_days` to always have summer timezone for the test. - adjusted some query counters to account for the extra search in `_attendance_intervals_batch` done by the method `_get_calendar_at` task-id: 5065160 Forward-Port-Of: odoo/enterprise#94715
This fixes an error that occurred when an HR responsible signed an employee offer involving requested extra time off with automatic allocation enabled. The change helps ensure the offer signing process completes smoothly when extra leave is part of the salary package workflow.
Original PR description
- When the employee requested extra time off, and the automatic allocation setting was turned on, signing the offer as the responsible HR caused an error. Task-5022631 Forward-Port-Of: odoo/enterprise#98195 Forward-Port-Of: odoo/enterprise#92663
This fixes a point-of-sale issue where clicking details within an order line could immediately close the numpad after opening it. Cashiers can now select order line details, such as eWallet balance information, without the numpad flickering or becoming unusable.
Original PR description
Steps to reproduce: =================== - Click on an orderline - Then click on a detail inside it (e.g., eWallet Balance line) - The numpad first opens and then closes right away Issue: ====== - Clicking on a detail inside the orderline makes the numpad open and close at the same time - This makes it impossible to use the numpad properly Cause: ====== - The click from the child element also reaches the main orderline click - Because of this, the numpad gets two clicks (open and close) Fix: ==== - Added `stopPropagation` in the click handler to block event bubbling - Now the numpad only reacts once and stays open as expected Task: 5000327 Forward-Port-Of: odoo/odoo#233201 Forward-Port-Of: odoo/odoo#227675
Sale orders that use only fixed taxes can now be read reliably through XML-RPC without causing a serialization error. This prevents integrations and external systems from failing when retrieving affected sales or accounting data.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Create a fixed tax; 2. create a sale order using only the fixed tax; 3. read the sale order via XML-RPC. Issue ----- TypeError: cannot marshal None unless allow_none is enabled Cause ----- If only a fixed tax is used, the `_get_tax_totals_summary` method returns a dict where the `display_base_amount_currency` and `display_base_amount` values are `None`, leading to an error serializing the result. Solution -------- As the result gets serialized by `OdooMarshaller(allow_none=False)`[^1], we should use `False` instead of `None`. [^1]: https://github.com/odoo/odoo/blob/b887bf2/odoo/addons/base/controllers/rpc.py#L114 opw-5173477 Forward-Port-Of: odoo/odoo#232955 Forward-Port-Of: odoo/odoo#232517
This fixes an upgrade issue where bank account setup could fail when no bank account code prefix was configured. The system now treats the missing prefix safely, helping affected accounting migrations complete without errors.
Original PR description
The 'bank_account_code_prefix' field is False by default instead of an empty string. This change ensures proper handling by falling back to an empty string when the field is False. ```traceback…
The 'bank_account_code_prefix' field is False by default instead of an empty string. This change ensures proper handling by falling back to an empty string when the field is False.
```traceback
module l10n_co: Running migration [$1.0] end-migrate_update_taxes
Traceback (most recent call last):
File "/home/odoo/src/odoo/18.0/odoo/service/server.py", line 1361, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "<decorator-gen-13>", line 2, in new
File "/home/odoo/src/odoo/18.0/odoo/tools/func.py", line 97, in locked
return func(inst, *args, **kwargs)
File "/home/odoo/src/odoo/18.0/odoo/modules/registry.py", line 129, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "/home/odoo/src/odoo/18.0/odoo/modules/loading.py", line 523, in load_modules
migrations.migrate_module(package, 'end')
File "/home/odoo/src/odoo/18.0/odoo/modules/migration.py", line 222, in migrate_module
exec_script(self.cr, installed_version, pyfile, pkg.name, stage, stageformat[stage] % version)
File "/home/odoo/src/odoo/18.0/odoo/modules/migration.py", line 259, in exec_script
mod.migrate(cr, installed_version)
File "/home/odoo/src/odoo/18.0/addons/l10n_co/migrations/1.0/end-migrate_update_taxes.py", line 8, in migrate
env['account.chart.template'].try_loading('co', company)
File "/home/odoo/src/odoo/18.0/addons/account/models/chart_template.py", line 160, in try_loading
return self._load(template_code, company, install_demo, force_create)
File "/home/odoo/src/odoo/18.0/addons/account/models/chart_template.py", line 228, in _load
self._post_load_data(template_code, company, template_data)
File "/home/odoo/src/enterprise/18.0/account_reports/models/chart_template.py", line 10, in _post_load_data
super()._post_load_data(template_code, company, template_data)
File "/home/odoo/src/odoo/18.0/addons/account/models/chart_template.py", line 681, in _post_load_data
self._setup_utility_bank_accounts(template_code, company, template_data)
File "/home/odoo/src/odoo/18.0/addons/account/models/chart_template.py", line 845, in _setup_utility_bank_accounts
accounts = self.env['account.account']._load_records([
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 5526, in _load_records
records = self._load_records_create([data['values'] for data in to_create])
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 5430, in _load_records_create
records = self.create(vals_list)
File "<decorator-gen-208>", line 2, in create
File "/home/odoo/src/odoo/18.0/odoo/api.py", line 498, in _model_create_multi
return create(self, arg)
File "/home/odoo/src/odoo/18.0/addons/account/models/account_account.py", line 997, in create
start_code = prefix.ljust(digits - 1, '0') + '1' if len(prefix) < digits else prefix
TypeError: object of type 'bool' has no len()
```
Databases affected by this traceback error:
https://upgrade.odoo.com/odoo/request/3191023/tbg/2150
task-5167397
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#232169This fix ensures employee work entries are generated correctly when staff have different working schedule types, flexible schedules, or schedule changes over time. It also prevents errors and incorrect time zones that could affect payroll-related records, including avoiding zero-duration entries for multi-day attendances.
Original PR description
- fixed work entries generation for employees with different working schedules types - fixed a traceback when the method `_attendance_intervals_batch` is called without a calendar (because the employee is fully flexible) or with more than 1 calendar - made work entries generation check for employee timezone incase the employee is fully flexible and doesn't have a calendar - added method _get_calendar_at to get the calendar of the resource at a given date - added `test_work_entry_different_calendars` for work entries generation for employees with contracts with different calendar types - fixed a timezone bug in `_generate_work_entries_postprocess` where `date_start_utc` and `date_start_utc` had `tzinfo = None` and not `utc` which resulted in having wrong timzones afterwards. - fixed a bug where a work entry with zero duration is created between days for attendances that span multiple days task-id: 5065160 Forward-Port-Of: odoo/odoo#226619
This fix prevents the messaging connection from wrongly treating a user as changed when some pages omit database details. Users keep their own presence updates reliably, so status changes across multiple browser windows are reflected correctly.
Original PR description
The websocket worker holds a single WebSocket connection per browser. Clients pass the current user ID and DB name, which the worker uses to detect login/logout. Some pages omit the DB name, causing…
The websocket worker holds a single WebSocket connection per browser. Clients pass the current user ID and DB name, which the worker uses to detect login/logout. Some pages omit the DB name, causing the worker to incorrectly mark the user as changed. This clears previous channels, which may never be added back. This is particularly noticeable with presence channels: the user's own channel can be lost, preventing them from receiving their own presence updates (e.g. when another browser closes, the user cannot see they are disconnected and cannot correct the value). The user's own presence channel should be added server-side, so the first subscription immediately returns the user presence and the DB should not be taken into account if ommited. task-5096212 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#233277 Forward-Port-Of: odoo/odoo#232984
This fix resolves an error that could stop customers from completing payments through Mercado Pago. It removes a faulty internal call so the payment form can proceed as expected.
Original PR description
'_super' is removed, since the binding of 'this' is no longer needed and since 'super' is not a function it caused an error and prevented the payment.
Administrators without Employees access can now open user records without hitting an employee permissions error. The HR calendar section is only shown to users with HR rights, preventing irrelevant employee data from blocking access.
Original PR description
Steps to reproduce : switch Marc Demo as "Administrator" + ensure we has no "Employees" rights, connect as him and try to open his user form view (Settings / Users / Users) it crashed with: "You do…
Steps to reproduce : switch Marc Demo as "Administrator" + ensure we has no "Employees" rights, connect as him and try to open his user form view (Settings / Users / Users) it crashed with: "You do not have enough rights to access the field "version_id" on Employee (hr.employee). Please contact your system administrator." Reason : a hidden Many2one field linking to hr.employee model, thus when the view is loaded this field causes an access to the model employee , given the current user doesn't have the rights , it causes an error. Fix : made the calendar page invisible for people with no hr rights , because there is a same view that can be accessed through the preference menu that contains the user's own info , otherwise , even with admin rights , if he doesn't have employee rights he is not concerned with the content of the calendar page of his or other user's form view. so it should be hidden from him. Fix : made the calendar page visible only for target users , in our case , users part of the following group : "hr.group_hr_user" task-5173101