Daily updates from Odoo
Tuesday, April 21, 2026
51 changes · saas-19.2
Enhancements to existing features
This change speeds up the validation of stock transfers that involve many move lines by grouping database actions instead of processing them one by one. It reduces delays and helps avoid timeouts on very large deliveries, improving reliability for busy operations.
Original PR description
Before this PR, `button_validate` was using a `write()` call per matched stock move. On every `write()` there is a Command.create and Command.delete which is resulting in N database round-trips for…
Before this PR, `button_validate` was using a `write()` call per matched stock move. On every `write()` there is a Command.create and Command.delete which is resulting in N database round-trips for the unlinks and N for the creates, followed by N separate `_apply_putaway_strategy()` calls. This is problematic for pickings with many move_ids. This PR attempts to accumulates all move lines to delete and to create. Then performs a single `unlink()` and `create()`, followed by a single `_apply_putaway_strategy()` for all pickings. Unlink is done using `.sudo()` to preserve the superuser context that was previously inherited implicitly through the `purchase_order.sudo().search` that produced the recordset used to obtain the `receipt_move`(s). Benchmarks: | No. move lines in delivery | Before | After | | -------------------------- | ------- | ----- | | 7579 | Timeout | < 200 s | opw-5826905 Forward-Port-Of: odoo/enterprise#110587 Forward-Port-Of: odoo/enterprise#110153
Assigning a chart of accounts or fiscal localization now uses much less memory and completes much faster on large databases. The update reduces the chance of failures during setup by moving heavy filtering work to the database and avoiding unnecessary data loading.
Original PR description
## Summary This PR optimizes memory consumption and execution time when assigning a **Chart of Accounts** or **Fiscal Localization**. By moving filtering logic to the database and preventing…
## Summary This PR optimizes memory consumption and execution time when assigning a **Chart of Accounts** or **Fiscal Localization**. By moving filtering logic to the database and preventing expensive field prefetching, we've achieved a **60% reduction in peak memory** and cut execution time by more than half on large datasets. ## The Problem Assigning a chart template was hitting memory limits on databases with a high volume of products (e.g., 2M+). Two main bottlenecks were identified: * **Inefficient filtering**: Loading all `product.template` <-> `tax` relations into the cache and filtering in-memory using python instead of using SQL. * **Excessive prefetching**: Accessing `product.product` fields (like `write_date`) inside the compute function triggered a cache miss that prefetched all product fields, consuming significant memory. ## Improvements * **SQL Filtering:** Pushed the `product_template` filtration logic to the SQL layer to reduce the amount of data loaded into the memory. * **Prefetching Prevention:** Optimized the compute logic to avoid triggering unnecessary field prefetching on `product.product`. --- ## Benchmarks *Tested using `memray` on a customer database with ~2 million products.* | Scenario | Duration | Peak Memory | Total Allocations | | :--- | :--- | :--- | :--- | | **Baseline (Before)** | 10:23.4 | 3.6 GB | 9,954,480 | | **Optimized Prefetching Only** | 10:21.0 | 2.3 GB | 9,292,271 | | **SQL Filtering Only** | 06:30.2 | 3.0 GB | 8,865,050 | | **Combined (Final Result)** | **04:59.6** | **1.4 GB** | **8,213,374** | ### Key Results: * **Memory Saved:** ~2.2 GB (61% reduction) * **Time Saved:** ~5.5 minutes (52% faster) OPW-6070666 Forward-Port-Of: odoo/odoo#259304
We improved how inventory valuation is calculated for past dates, especially for AVCO products. The system now limits unnecessary historical quantity checks, which makes large inventory calculations much faster without changing the result.
Original PR description
When computing Inventory Valuation with a past `As of` date for AVCO products, `_run_average_batch()` reads `qty_available` for each manual `product.value` entry with `product.with_context(to_date=manual_value.date).qty_available`. On large databases, products can carry a broad prefetch set through the `product.value` browsing path. As a result, each distinct `to_date` may compute `qty_available` for more products than necessary. This change narrows the prefetch ids to the products sharing the same manual value date before reading `qty_available`. This keeps the same `to_date`, the same quantity computation, and the same per-product result, while reducing the amount of historical quantity computation done for each date. | Stock moves | Before PR | After PR | | --- | ---: | ---: | | 785k | fails after ~900s | 183s | opw-5944584 Forward-Port-Of: odoo/odoo#256684
Resolved issues and error corrections
Imported invoices could show the wrong tax amount when an electronic invoice contained multiple tax subtotal sections. The fix ensures Odoo only uses the tax total tied to the invoice’s own currency, which keeps imported amounts accurate and avoids reporting errors.
Original PR description
When the EDI document has multiple document-level TaxSubtotal nodes (which can happen under Japanese PINT rules), `_correct_invoice_tax_amount` erroneously amends the tax total, and the imported invoice gets the wrong value. In BIS3 EDI, two TaxTotal nodes are created if the document currency and the company currency are different. The TaxTotal node in the company currency is generally for tax reporting purposes. Up until now, `_correct_invoice_tax_amount` worked correctly because base BIS3 EDI requires TaxTotal nodes with the document currency to have a TaxSubtotal node. This commit fixes the bug by only correcting the taxes based on the TaxTotal node that has a currency ID equal to the document currency. Note 1: This fix is targeting 19.0 and above because `l10n_jp_ubl_pint` and other PINT modules are available starting from 19.0. Forward-Port-Of: odoo/odoo#258301
Searching for people to invite to a channel is now much faster. The system avoids extra work behind the scenes and shows only as many results as can fit on screen, improving responsiveness for users.
Original PR description
Since [1], the check in `search_for_channel_invite` that restricted the search to internal users was removed. As a result, the dataset to process has exploded and the query is very slow. Moreover,…
Since [1], the check in `search_for_channel_invite` that restricted the search to internal users was removed. As a result, the dataset to process has exploded and the query is very slow. Moreover, the method is ordering on `LOWER(name)` which is not indexed, and another query is done to count the total results, which slows down the process even more. This PR fixes those issues by: - Removing the `LOWER` ordering. Ordering in a case sensitive fashion is not that big of a deal anyway. - Removing the count query, fetching one more partner in the search is enough to know if there are more results, executing the same query twice is overkill. - Reducing the number of partner returned: currently 30, but there isn't enough space to display them anyway. task-4526176 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
This change prevents an error when opening a BoM Overview for a company that does not yet have a warehouse configured. Instead of failing, the overview now shows product availability as unavailable until a warehouse is set up. This makes the feature safer to use in newly created companies and avoids a blocking error.
Original PR description
**Steps to Reproduce:** - Install MRP module. - Create a new company and switch to it. - Create a new BoM. - Click on the "BoM Overview" smart button. **Error:** `IndexError - list index out of range` **Cause:** When a new company is created, no warehouse is automatically generated for it. If no warehouse is configured for the company, the list is empty, causing an error. **Fix:** This commit raises a redirection warning if no warehouse is linked with the company. sentry-7286332859 Forward-Port-Of: odoo/odoo#250602
This update prevents an error that could appear when users remove an attachment from a scheduled chat message. It makes the scheduled message editor behave correctly and avoids an unexpected traceback during message editing.
Original PR description
scheduled message editor Problem: When editing a scheduled chatter message, removing an attachment raises a traceback. Cause: `fullComposerBus` is available in the `Composer` environment but not in `ScheduledMessage`. The code assumed its presence and attempted to use it unconditionally. Solution: Check whether `fullComposerBus` exists in `env` before using it. Steps to reproduce: - Add a log note. - Open the full Composer. - Add an attachment. - Schedule the message. - Save. - Edit the scheduled message. - Remove the attachment from the attachments list. - Observe a traceback. opw-6098302 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258839
When users change fields in the holiday request pop-up, those updated values are now saved correctly. This prevents users from losing edits and makes request handling more reliable.
When sending invoices by email, extra attached reports now use the name configured on the report instead of being renamed with a default pattern. This makes emailed documents easier to recognize and ensures customer-facing PDFs match the business’s chosen naming.
Original PR description
When sending an invoice by email template, dynamic report attachments do not use their configured Printed Report Name. Instead, they fall back to a default naming pattern (e.g. report name + invoice…
When sending an invoice by email template, dynamic report attachments do not use their configured Printed Report Name. Instead, they fall back to a default naming pattern (e.g. report name + invoice number). This is due to a difference in flow: sales use the standard mail.compose.message wizard, which correctly applies each report’s print_report_name, while invoices use the dedicated account.move.send flow. In this flow, dynamic report filenames are not computed from the report itself. To fix this, the send flow is updated so _get_placeholder_mail_template_dynamic_attachments_data computes the filename from each dynamic report. When a print_report_name is defined, it is used. Otherwise, the previous fallback behavior is preserved. The fix will ensure extra dynamic reports follow their configured printed name. Steps to reproduce: 1. Go to Settings > Technical > Reporting > Reports and duplicate the standard Invoice report. 2. In the duplicated report, set a custom value in Printed Report Name (e.g. 'CUSTOM_NAME_TEST'). 3. Go to Settings > Technical > Email > Templates and open “Invoice: Sending”. 4. Add the duplicated report under Dynamic Reports. 5. Create a customer invoice and confirm it. 3. Click Send (or Send & Print) to open the email preview. Related Ticket: opw-6058716 Forward-Port-Of: odoo/odoo#259975 Forward-Port-Of: odoo/odoo#259267
This update makes sure retried tests keep track of the latest test instance instead of reusing an older one. That helps avoid issues when the system opens a test cursor, improving the reliability of automated test runs.
Original PR description
When a test is retried, the current_test variable was not updated to the new test instance, which could lead to issues when opening a test cursor. This commit ensures that current_test is updated on each retry attempt. While there update the condition to have a stronger check in this specific case since test equality only uses test name Forward-Port-Of: odoo/odoo#260148
Preparation tickets now show the selected product variant for instant variants included in combo choices, instead of only showing the base product name. This helps kitchen and fulfillment teams identify the exact item ordered and reduces preparation mistakes.
Original PR description
Before this commit, the preparation printer did not display the attribute value for an instant variant added inside a combo choice. This occurred because the attribute value was not properly set on the variant order line. Steps to reproduce: * Create a PoS product with multiple variants. * Create a combo product with a choice containing the variants. * Configure a preparation printer. * Open a PoS session and order the combo. * The printer displays only the base product name. opw-5949132 Forward-Port-Of: odoo/odoo#256981
The Barcode app no longer shows a location confirmation warning when users add a product that is not meant to be stored in inventory. This makes the workflow smoother and prevents unnecessary prompts during picking operations.
Original PR description
### Steps to reproduce: - In the settings: Enable Multi-Steps Routes - Create a non-storable product P - Go to the barcode app > Operations > Delivery Order > New - Click on "Add Product" > select P…
### Steps to reproduce: - In the settings: Enable Multi-Steps Routes - Create a non-storable product P - Go to the barcode app > Operations > Delivery Order > New - Click on "Add Product" > select P as product > Confirm #### > A confirmation dialog appears: Oops! It seems that this product is not located in WH/Stock. Do you confirm you picked from there? ### Expected behavior: Since the product is not storable it should not trigger the dialog ### Cause of the issue: The `is_storable` value of the `product.product` is not part of the data that can be used to check if we should check the quantity available in location since only the product id and name are directly available: https://github.com/odoo/enterprise/blob/77d3cc81be8aeb9f2e8bf57fb561fcae80f23b04/stock_barcode/static/src/js/stock_barcode_sml_form.js#L40-L70 However, since an rpc is already performed in order to determine the `qty_available` of the product, we might as well use that same rpc to recover the information and also avoid the dialog in case it is irrelevant. opw-6110655 Forward-Port-Of: odoo/enterprise#114173
This update prevents custom fields from being duplicated when the system reloads model definitions. It helps keep the application registry clean and avoids inconsistent behavior caused by leftover field entries.
Original PR description
When a custom (manual) field is related to a base field, it is added to `registry.field_setup_dependents`. However, these custom fields were not being cleaned up correctly, causing them to duplicate and leak during each model setup. This fix explicitly cleans these manual fields from `field_setup_dependents` inside `_add_manual_models()` when manual models are removed from the registry and the registry is being reloaded. Similar to https://github.com/odoo/odoo/pull/253377. Forward-Port-Of: odoo/odoo#259819
The editor now avoids showing formatting tools on parts of a page that cannot be edited. This prevents errors and unexpected changes when users work with locked content, while still allowing the toolbar for special editable elements like QWeb and icons.
Original PR description
Current behavior before PR: - Removing formatting on a contenteditable false element infinite loop when removing format. - The toolbar could appear even when the target element had contenteditable false Desired behavior after PR is merged: - Now,the toolbar no longer opens when the selected element is contenteditable false - The toolbar is now only shown for elements with contenteditable true, except for QWeb and icon elements, where it remains accessible. task-5265416 Forward-Port-Of: odoo/odoo#259453 Forward-Port-Of: odoo/odoo#231613
This change prevents a checkout failure that could happen when paying for a cart created with a company account whose contacts are linked to active users. Odoo now checks for active users on related contacts before archiving them, so payments can complete normally instead of stopping with an error.
Original PR description
Use case: - considering a database where `website_event_booth_sale` is installed - considering a company (ACME Corp., email: info@acme.example.net) and it's contact `Roger` (which have a valid user). then: - As an anonymous user, go to an event with some booth to register - register a booth and enter the company information (important: use the company email: info@acme.example.net, this way the cart is created the company as the `partner_id` !!!) - you are redirected to the cart - try to pay it, and upon payment you have the following error: ``` You cannot archive contacts linked to an active user. You first need to archive their associated user. ``` This commit ensure we also check if any contact of the commercial partner have any user before trying to archive them all. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259451
When users click “View Profile” from a partner mention, the contact form now opens and the avatar popover closes at the same time. This avoids having two overlapping windows on screen and makes the experience cleaner and less confusing.
Original PR description
**Current behavior before PR:** Clicking on a partner mention opens the avatar card popover. When the **View Profile** button is clicked, the partner form view opens, but the popover remains visible. This happens because the popover opened via `onClickPartnerMention` uses the popover service directly, instead of the `usePopover` hook, which automatically closes the popover when the component is unmounted. **Desired behavior after PR is merged:** Clicking the **View Profile** button opens the partner form view and closes the avatar card popover. task-[6063906](https://www.odoo.com/odoo/project/1519/tasks/6063906) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259959 Forward-Port-Of: odoo/odoo#256283
This fix prevents an error when users add multiple tags to a blog post cover and one of the tags has not been fully created yet. It improves the editing experience by avoiding a traceback and letting users continue selecting tags normally.
Original PR description
# How to reproduce - Go to a blog page and edit the Blog Post Cover - Add a tag - Try to add another one # The problem A traceback is shown # Why When adding a new record for a many 2 many relation, the framework ensure the user cannot create a record with a name that already exists via a name search. This commit (https://github.com/odoo/odoo/commit/3631757a4766bc59378bb975e01e115c92ef1dd4) changed the way the name search is done to add this domain to the request : ```py domain.push(["id", "not in", selectedIds]); ``` But selectedIds can contain strings in the case of uncreated records, which causes the SQL query to throw an error trying to match the model id with strings opw-5978305 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258451 Forward-Port-Of: odoo/odoo#251469
Access error messages now better identify the real reason a record is blocked. This prevents users from being misled into thinking a company access issue is the cause when another rule is actually responsible.
Original PR description
When accessing an archived record directly, if access is prevented by a record rule other than a multi-company global rule, the error message incorrectly reports that all rules are failing, suggesting a company issue even though it is not the actual cause. The problem is that when access is denied, the diagnostic method `_get_failing` is used to determine which rules are failing. This method performs several count queries with different rule domains. However, `active_test` is True by default, excluding archived records from the count, causing the rule evaluation to miss some records and incorrectly mark rules as failing. With this commit, `_get_failing` evaluates rules with `active_test=False`, ensuring that only actually failing rules are reported. Forward-Port-Of: odoo/odoo#259592 Forward-Port-Of: odoo/odoo#259344
When editing Arabic or other right-to-left content, the editor now matches the direction of the site being edited instead of the logged-in user’s interface language. This prevents text from appearing in the wrong alignment while writing and makes the editing experience consistent with the published page.
Original PR description
Steps to reproduce: ==================== 1. Install Arabic and set it as a website language 2. Log in as a user whose UI language is English 3. Edit a page / article in Arabic and type some text =>…
Steps to reproduce: ==================== 1. Install Arabic and set it as a website language 2. Log in as a user whose UI language is English 3. Edit a page / article in Arabic and type some text => Text rendered left-to-right in the editor Cause: ======= this was introduced after this change [1] When editing a website/article in a language whose direction differs from the logged-in user's UI language, text entered in the builder appeared in the wrong direction (e.g. writing in Arabic showed the caret/text aligned to the left instead of the right). Saving reverted the content to the correct direction, but the authoring experience was broken. The builder was initializing the editor's `direction` config from `localization.direction`, i.e. the *user's* UI locale, instead of the direction of the document being edited. As a result, an LTR admin editing an RTL site (or the reverse) got an editable whose `dir` attribute did not match the site. Solution: ========= Use the editable itself as the source of truth: if it carries the `.o_rtl` class (already used to set `isEditableRTL`), set `direction = "rtl"`, otherwise `"ltr"`. => Text now renders right-to-left, matching the site [1]:https://github.com/odoo/odoo/pull/256045/changes/0490b2229dba7e0cb4a58e5cf4d68772e5640697 opw-6109987 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259541
The domain selector and expression editor now show numbers using the user’s local formatting, including the correct decimal and thousands separators. This makes values easier to read and reduces confusion, while keeping the underlying expression unchanged.
Original PR description
Before this commit, the domain selector (and expression editor) did not format numbers according to the localization parameters (decimal and thousands separators), while the parsing step did. After this commit, the value is displayed in the correct format to the user, while the expression remains unchanged. 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#259732 Forward-Port-Of: odoo/odoo#258287
Employee search in Attendance kiosk mode now handles certain department filters correctly and no longer crashes with an error. This makes it easier for staff to find employees at the kiosk without interruption.
Original PR description
**Steps to Reproduce:**
1. Install `hr_attendance` module with demo data.
2. Go to Attendances > Kiosk Mode > Identify Manually.
3. Select any department.
4. Try searching for an employee.
**Error:**
`ValueError - not enough values to unpack (expected 3, got 1)`
**Cause:**
The `employees_infos()` controller assumes that every item in the domain is a valid triplet (field, operator, value). However, the domain may also contain logical operators ('&'), which are not triplets. And then trying to unpack such entries leads to a ValueError.
**Fix:**
Add a validation to ensure the condition is a proper triplet before unpacking. Non-conforming entries (logical operators) are skipped.
sentry-7401444075
opw-6113268
Forward-Port-Of: odoo/odoo#258825This change fixes an issue where the color picker would close immediately after hovering a color on selected icons. It restores the intended behavior so users can change icon colors normally in the editor.
Original PR description
Commit [1] did already fix this problem, but commit [2] broke it again. This commit restores the condition that was removed by [2] but adapts it slightly in order to only take into account the direct children of the node, instead of any sub-node when checking for the presence of icons. Steps to reproduce: - Go to a "To do" note - Insert an icon with /media - Select the icon - Open the color picker - Hover a color => Color picker closed right away [1]: https://github.com/odoo/odoo/commit/1adfd9b9daf09c26ad642faf411574123110b9be [2]: https://github.com/odoo/odoo/commit/85688ffd11a3a988bf32c8c923a4628a89b57f87 task-6128069 Forward-Port-Of: odoo/odoo#260014 Forward-Port-Of: odoo/odoo#259644
This fix ensures desktop activity matched by a rule is linked to the project selected in that rule, even when no task is set. As a result, time suggestions appear in the right place instead of showing as unmatched, making timesheet tracking more reliable.
Original PR description
Steps to Reproduce --- - Define an aw.rule with a project set without a task (false) - The rule regex matches a desktop app event (e.g. Discord window) - Open the Timesheets Assistant for the current…
Steps to Reproduce --- - Define an aw.rule with a project set without a task (false) - The rule regex matches a desktop app event (e.g. Discord window) - Open the Timesheets Assistant for the current day Current Behavior --- - The matched event has _res_model set to "project.task" and _res_id set to undefined, despite no task being configured on the rule - The suggestion appears as "Unmatched" in the assistant even though a project was correctly defined on the rule Expected Behavior --- - The matched event should have _res_model set to "project.project" and _res_id set to the rule's project_id - The suggestion should appear under the configured project Issue --- - In extractWatcherActivity(), both project_id and task_id blocks used != null as the guard condition - When task_id is false, false[0] is undefined, overwriting the correctly set _res_model i.e. "project.project" and _res_id from the project_id block with "project.task" and undefined _res_id Fix --- - Replace with a truthy check task - 6089410 Forward-Port-Of: odoo/enterprise#114172
The spreadsheet component has been refreshed to its latest version, bringing multiple fixes and internal updates that improve reliability and compatibility. This includes corrections for formatting, pivot tables, copy/paste behavior, and visual polish, helping users avoid crashes and inconsistent results while working in spreadsheets.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/1ebe03d162 [REL] 19.2.8 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/1ebe03d162 [REL] 19.2.8 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/5fad815249 [IMP] package: backport rolldown and TS 6.0 [](https://www.odoo.com/odoo/2328/tasks/) https://github.com/odoo/o-spreadsheet/commit/030d3793ce [IMP] typescript: upgrade to 6.0.2 [Task: 6119495](https://www.odoo.com/odoo/2328/tasks/6119495) https://github.com/odoo/o-spreadsheet/commit/941bb93a5e [FIX] package: add rolldown binaries to optional dependencies [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/e2c1b4a0dc [IMP] package: upgrade rolldown to latest version [Task: 6119495](https://www.odoo.com/odoo/2328/tasks/6119495) https://github.com/odoo/o-spreadsheet/commit/99b0d19d69 [IMP] config: rename rolldown config file [Task: 6071659](https://www.odoo.com/odoo/2328/tasks/6071659) https://github.com/odoo/o-spreadsheet/commit/28652dab8c [IMP] config: replace rollup with rolldown [Task: 6119495](https://www.odoo.com/odoo/2328/tasks/6119495) https://github.com/odoo/o-spreadsheet/commit/3b19f6d042 [IMP] eslint: enforce type exports [Task: 6119495](https://www.odoo.com/odoo/2328/tasks/6119495) https://github.com/odoo/o-spreadsheet/commit/e7fb830b27 [IMP] pre-commit: bypass eslint's typescript compilation [](https://www.odoo.com/odoo/2328/tasks/) https://github.com/odoo/o-spreadsheet/commit/d2ed012bc6 [IMP] tsconfig: moduleResolution bundler [Task: 6119495](https://www.odoo.com/odoo/2328/tasks/6119495) https://github.com/odoo/o-spreadsheet/commit/d5cf819fdc [FIX] format: keep negative accounting suffix in large number [Task: 6068834](https://www.odoo.com/odoo/2328/tasks/6068834) https://github.com/odoo/o-spreadsheet/commit/a55057c702 [FIX] spreadsheet_pivot: avoid crash on invalid dimension values [Task: 6111913](https://www.odoo.com/odoo/2328/tasks/6111913) https://github.com/odoo/o-spreadsheet/commit/dcd5903f24 [FIX] side_panel: prevent chart picker layout shift on hover [Task: 6095239](https://www.odoo.com/odoo/2328/tasks/6095239) https://github.com/odoo/o-spreadsheet/commit/665d9f303d [IMP] tests: add tests for `chartShowValuesPlugin` [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/de634c5865 [FIX] clipboard: prevent cross-version copy/paste [Task: 6095101](https://www.odoo.com/odoo/2328/tasks/6095101) https://github.com/odoo/o-spreadsheet/commit/a9fbc7b0d8 [FIX] css: remove unused variables [Task: 6119435](https://www.odoo.com/odoo/2328/tasks/6119435) https://github.com/odoo/o-spreadsheet/commit/20d0cb4982 [FIX] computed style: fix multi-user clear formatting [Task: 6086129](https://www.odoo.com/odoo/2328/tasks/6086129) https://github.com/odoo/o-spreadsheet/commit/c3b64a3683 [FIX] format: large number format with no digits [Task: 6010376](https://www.odoo.com/odoo/2328/tasks/6010376) https://github.com/odoo/o-spreadsheet/commit/19a3cfb895 [FIX] format: number format with no digit [Task: 6068824](https://www.odoo.com/odoo/2328/tasks/6068824) https://github.com/odoo/o-spreadsheet/commit/903fb2bd26 [FIX] pivot cell style copied twice [Task: 5909138](https://www.odoo.com/odoo/2328/tasks/5909138) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
Sending password reset instructions to several users at once no longer triggers an error. The fix ensures the email content is generated correctly for each user, so administrators can use the bulk action without interruption.
Original PR description
Currently, an error occurs when sending the password reset link to multiple users. **Steps to Reproduce:** - Install `auth_signup` module. - Go to `Users` and make sure there are at least two user…
Currently, an error occurs when sending the password reset link to multiple users.
**Steps to Reproduce:**
- Install `auth_signup` module.
- Go to `Users` and make sure there are at least two user records.
- In the `list view`, select both users.
- Go to `Actions` > click `Send Password Reset Instructions`.
`ValueError: ValueError('Expected singleton: res.users(24, 23)') while evaluating 'records.action_reset_password()'`
This error occurs when generating the email body_html [1]. It passes multiple user
records (self) as the context record, but _render_encapsulate expects a single user
record to render the email body. which raise the error here[2].
This commit passes a single user record when rendering body_html.
[1]: https://github.com/odoo/odoo/blob/39c6e3a2578c4f7058dddb6acf12231d8716e7fd/addons/auth_signup/models/res_users.py#L214
[2]: https://github.com/odoo/odoo/blob/39c6e3a2578c4f7058dddb6acf12231d8716e7fd/addons/mail/models/mail_render_mixin.py#L187
sentry-7271437735
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#249206The Timesheet Assistant now ignores calendar entries created from time off requests. This prevents employees from seeing time off as a work suggestion in Timesheets, making the assistant’s recommendations more accurate and less confusing.
Original PR description
Steps to Reproduce:
---
1. Book a time off for any day via the Time Off app.
2. Open the Timesheets app for that same day.
3. Open the Timesheet Assistant suggestions panel.
Current Behavior:
---
The assistant surfaces the calendar event generated by the Time Off app as a
timesheet suggestion, e.g."Calendar Event - Mitchell Admin on Time Off : 1 days"
Expected Behavior:
---
Calendar events created by time off requests should not appear as
timesheet suggestions.
Issue:
---
The get_calendar_events getter in timesheet_grid_calendar fetched all calendar event
for the user without filtering by res_model, so time off meetings were included.
Fix:
---
Add ("res_model", "!=", "hr.leave") to the calendar.event search
domain.
task-6117932
Forward-Port-Of: odoo/enterprise#113789Website editor now shows the translation status marker correctly on file names added through the file element, even when the name sits over a colored background. This makes it easier for users to see whether a file name still needs translation when editing multilingual pages.
Original PR description
Commit cbb2eb2edfeecbc21a70c1a3cba81ad0a7ac9c75 added a resource to repeat the background color of the translation state inside elements, for the cases where an element has a background color that hides the translation state. This commit uses the resource for file's names (added by typing `/file`) Steps to reproduce: - Open website builder - Type `/file` and add a file - Add a language - Open in translate mode - Bug: the translation state is not show on the file name task-6038029 Forward-Port-Of: odoo/odoo#259955 Forward-Port-Of: odoo/odoo#259902
There were some translation overrides for `fr_BE` and `fr_CA` that were incorrect or unnecessary. We are deleting these files so they use the correct translations in `fr` instead. In the `nl_BE` translation, we are fixing a menu item so it is shorter, but still correct. task-5921458 Forward-Port-Of: odoo/enterprise#114197 Forward-Port-Of: odoo/enterprise#106998
Original PR description
There were some translation overrides for `fr_BE` and `fr_CA` that were incorrect or unnecessary. We are deleting these files so they use the correct translations in `fr` instead. In the `nl_BE` translation, we are fixing a menu item so it is shorter, but still correct. task-5921458 Forward-Port-Of: odoo/enterprise#114197 Forward-Port-Of: odoo/enterprise#106998
This change corrects how unit prices are written into Peppol invoice files so they match the calculated line total exactly. It prevents invoices from being rejected by Peppol validation when prices have many decimal places.
Original PR description
**PROBLEM** Previously, we rounded the unit price up to 6 digits in the generated xml for peppol. However, odoo compute the lineExtensionAmount with the raw unit price. The generated xml is invalid because `priceAmount*InvoicedQuantity != LineExtensionAmount`. **STEP TO REPRODUCE** 1. Create an invoice with unit price of 0.01110515964, and quantity of 278362.5. 2. Generate an XML with peppol, and try validating the invoice. You should have the following error: `[PEPPOL-EN16931-R120]-Invoice line net amount MUST equal (Invoiced quantity * (Item net price/item price base quantity) + Sum of invoice line charge amount - sum of invoice line allowance amount` opw-6009771 Forward-Port-Of: odoo/odoo#259759 Forward-Port-Of: odoo/odoo#255358
This change removes unwanted empty lines at the beginning and end of messages before they are sent. It helps make outgoing messages look cleaner and more consistent for recipients.
Original PR description
Trim the leading and trailing empty lines in the message body before sending it to avoid unwanted empty lines at the beginning and end of messages. task-6027013 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259723 Forward-Port-Of: odoo/odoo#259136
This change updates test data for Peru electronic invoicing to match the corrected unit price rounding behavior. It helps keep the automated checks reliable so future updates do not introduce regressions in this local accounting flow.
Original PR description
https://github.com/odoo/odoo/commit/e79136d04c844f9a0a8c6d0532c65e0cc3a68b8f fixes unit price rounding in peppol. This PR fixes a broken test in l10n_pe_edi opw-6009771 Forward-Port-Of: odoo/enterprise#114159
The POS due settlement flow now correctly includes refund orders when calculating what a customer still owes. This ensures the amount shown and settled reflects the true net balance, preventing customers from being overcharged or under-settled.
Original PR description
Step to reproduce - install "pos_settle_due" - have a customer, A and a pos with payment method "customer Account" - start pos, add 3 qty of product with unit price 10$ with partner A - use payment method "customer Account" i.e. of type "pay_later" (do not invoice orders) - refund 1 qty of previous order using same payment method - go to partner list, notice A has 20$ as due - click on "hamburger btn" > settle due amount Observation: - notice we only get the order amount as due i.e order with 30$ - we should have received the refund order too, so that net due of 20$ can be processed Cause: - currently, we didn't considered refunds orders at all, when settling dues Fix: - now we consider order with total < 0 i.e refund orders to be included for settlement opw-5869313 Forward-Port-Of: odoo/enterprise#113950 Forward-Port-Of: odoo/enterprise#107883
This fix allows Point of Sale to sell event tickets even when a multi-slot event has unlimited availability. Previously, those tickets could incorrectly appear as sold out, preventing customers from completing their purchase.
Original PR description
**Steps to reproduce:** - Make an event, put it to announced state - Allow multi slots and create a product - Go to the pos and try to order it - "All slots are booked out for this event" appears **Why the fix:** When we set 0 as a maximum quantity for an event slot, the quantity is unlimited, in the code, the availability is set to a string "unlimited". This was not taken into account in the case of multi slots, as we only checked if the availability was a number greater than 0. As "unlimited" is not a number, we thought we didn't have any slots available and returned the error that said all slots were full. We now add the unlimited tickets to the availability list. opw-6006696 Forward-Port-Of: odoo/odoo#254220
This update prevents timesheet information from overlapping when users scroll in the attendance systray on smaller screens. It also adjusts the layout so the list and checkout button stay readable and avoids awkward double scrolling.
Original PR description
Before: The systray overlaps the records when scrolling on small screens Changes: - Expands the record list to avoid scrolling overlaps - Make the timesheet list expand before the checkout button to ensure no overlap - Restrict the height of the timesheet list to avoid the double-scrolling problem --- task: 6115674
This update corrects how invoice line amounts are exported in the Luxembourg FAIA XML file when a line has a negative unit price. It ensures debit and credit values are reported consistently, preventing validation errors during file checks and submission.
Original PR description
This is one of several commits fixing the FAIA xml export: - #113452 - #113455 - #113846 - #113720 When an invoice line has a negative `price_unit`, the `Invoice/Line/InvoiceLineAmount/Amount` element has a negative value. This causes validation errors when comparing the total debit or credit values (such as `SalesInvoices/TotalDebit`) to the individual amounts, as the sum of individual "debit" lines will include some credit amounts and vice versa. Solution: record if the line is actually a debit or a credit, then use the absolute value of the balance in the Amount element. opw-5427296 [Link](https://www.odoo.com/odoo/unassigned-tasks/5427296) Forward-Port-Of: odoo/enterprise#113606 Forward-Port-Of: odoo/enterprise#113316
The CRM onboarding tour now places the lead generation steps at the end, preventing the tour from getting stuck or looping back on itself. This makes the guided experience more reliable for users trying out lead generation in CRM.
Original PR description
The crm_iap_mine module extended the crm tour, by adding steps to introduce the lead generation feature. These steps were inserted in the middle of the tour, which caused the tour to backtrack and…
The crm_iap_mine module extended the crm tour, by adding steps to introduce the lead generation feature. These steps were inserted in the middle of the tour, which caused the tour to backtrack and loop on itself. Why? For the tour to wait for the next step, we specify the selectors it should look for. In this case, because the modal redirects to the same page (with an updated domain), we cannot specify a selector that would be unique to the new page -> the target is found before the redirect -> after the redirect happens, the tour backtracks to try and recover, causing the loop. Moving the steps to the end of the tour fixes the issue. The disadvantage of this is that no the last step of the tour is not deterministic - it can fail if the user selects a combination of countries and industries which have no valid leads (Antarctica...) or if the user doesn't have enough IAP credits. In this case, the 'Congrats' rainbowman is shown even if the generation failed. Task-5386684 Forward-Port-Of: odoo/odoo#259960 Forward-Port-Of: odoo/odoo#249733
This update replaces the removed payslip line editing wizard with direct, inline payroll computation. It keeps payroll adjustments working smoothly while reducing the chance of interruption for users managing payslips.
Original PR description
We replace the previously removed payslip line edition wizard with inline payslip computation
Belgian Intervat settings are now shown not only for companies based in Belgium, but also for companies that use Belgian taxes through a Belgian fiscal position. This means users can review, change, or disable Intervat configuration even when the company itself is not registered in Belgium.
Original PR description
### Issue: When demo data is disabled, creating a Belgian fiscal position installs the Belgian taxes and enables BE accounting Starting from 19.0, Intervat redirection is enabled automatically, but the Intervat settings are not available because the company itself is not Belgian As a result, the Intervat configuration cannot be changed or disabled ### Cause: The Intervat settings were only shown when the company country was Belgium However, companies using Belgian taxes through `account_enabled_tax_country_ids` must also be considered ### Steps to reproduce: - Disable demo data and install `accountant` - Create a Fiscal Position "Belgium" (Country: Belgium, Foreign Tax ID: BE010203040) - Click the alert to install the Belgian taxes - Open Settings Before the fix: The Intervat settings are not available opw-6068480 Forward-Port-Of: odoo/enterprise#112609
This change prevents an error that could appear when a user tries to confirm a scrap after first dismissing the insufficient quantity warning. It ensures the system only removes the related scrap record in the right flow, so users can safely continue without seeing a traceback.
Original PR description
**Version:** --------- - saas-19.2+ **Steps to reproduce:** ------------------------ * Install the *Inventory (stock)* module. * Create a *storable product* with tracking enabled. * Update the…
**Version:** --------- - saas-19.2+ **Steps to reproduce:** ------------------------ * Install the *Inventory (stock)* module. * Create a *storable product* with tracking enabled. * Update the on-hand quantity to *5 units*. * Navigate to *Inventory > Operations > Scrap* and create a new scrap record. * Select the created product and set a quantity *greater than the available on-hand quantity (e.g. 6)*. * Click on *Confirm*. * An *insufficient quantity* wizard opens. * Click on *Discard*. * Then click again on *Confirm* in the wizard. **Issue:** --------- * A traceback occurs with the following error: `ValueError: Expected singleton: stock.move()` **Cause:** ---------- * When clicking *Confirm*, button the insufficient quantity wizard is opened with a `scrap_move_id`. https://github.com/odoo/odoo/blob/3206cd9bc0af33b047138fc6666a14f8d11da785/addons/stock/models/stock_move.py#L2747 https://github.com/odoo/odoo/blob/3206cd9bc0af33b047138fc6666a14f8d11da785/addons/stock/models/stock_move.py#L2742 * Clicking *Discard* button triggers `action_cancel`, which unlinks the associated `scrap_move_id`. https://github.com/odoo/odoo/blob/3206cd9bc0af33b047138fc6666a14f8d11da785/addons/stock/wizard/stock_warn_insufficient_qty.py#L48-L49 * However, the wizard remains open, and clicking *Confirm* again triggers `action_done`, which calls: https://github.com/odoo/odoo/blob/3206cd9bc0af33b047138fc6666a14f8d11da785/addons/stock/wizard/stock_warn_insufficient_qty.py#L46 * At this point, `scrap_move_id` no longer exists, leading to the singleton error. - Before saas-19.2 This behavior was previously handled in: https://github.com/odoo/odoo/commit/c361c3778ef4755b4760039a4fd8f9ed88294b64 Later in this commit https://github.com/odoo/odoo/commit/1c7d80a10b5d7db1c4163166bf52b3f3c77044ba the condition was removed during refactoring, causing the scrap move is to be unlinked in all flows. **Fix:** ------ * Add a context key to ensure that the scrap move is only unlinked during the `action_scrap` flow, preventing access to a deleted `scrap_move_id`. --- opw-6128188 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update removes the hover tooltip that appeared for boolean fields in calendar popups. It prevents confusing or unhelpful content from showing when users move their mouse over these fields.
Original PR description
Before this commit, the tooltip of a boolean field in calendar popover shows html content when the user hovers the boolean field. This commit removes the tooltip of boolean field in calendar popover since the information inside that tooltip is not really useful for the user. Issue found during the development of task-5994205 Forward-Port-Of: odoo/odoo#259529 Forward-Port-Of: odoo/odoo#259011
The digest now counts connected users based on the companies they are allowed to access, instead of only their default company. This makes the KPI more reliable for people who work across multiple companies and avoids undercounting in the digest report.
Original PR description
**Problem:** Currently, the digest KPI for connected users checks the "company_id" field (as with all other models), but this field corresponds to "Default Company" on res.users, meaning a user can only be considered for one company when computing the digest KPI. This can cause misleading digest KPIs if users work in multiple companies, or mainly in a company that isn't their default company. **Solution:** Instead of always using the "company_id" field, we use the "company_ids" field if present on the model. opw-5404940 Forward-Port-Of: odoo/odoo#259345 Forward-Port-Of: odoo/odoo#247806
This change corrects a bug in the upgrade script so it properly recognizes when a variable is actually being used, even if it is followed by a comma. This prevents the script from making unnecessary template changes during upgrades.
Original PR description
When a variable is used as method parameter and followed by a comma it failed to be identified as being used, so the script then incorrectly moved it as a t-call parameter while it's not necessary.
In the example below, the variable `geoip_country` was not correctly identified as being used in the `t-out` statement:
```
<t t-name="website.test">
<t t-call="website.layout">
<t t-set="geoip_country" t-value="request.geoip.country_code"/>
<t t-set="all_countries" t-value="{cc.code: cc.name for cc in request.env['res.country'].search_fetch([], ['code', 'name'])}"/>
<div>Country: <t t-out="all_countries.get(geoip_country, 'BE')"/></div>
</t>
</t>
```
This commit fix used variable detection when the variable is immediately followed by a comma.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#258838This change prevents an error when downloading a receipt for a POS order in an Indian company. It ensures the receipt is generated using the correct company context, so the required receipt information is included and the download completes successfully.
Original PR description
When a user attempts to download a POS order receipt for an Indian company, a traceback is raised. Steps to reproduce the error: - Install ``l10n_in_pos`` module with demo data - Switch to IN Company…
When a user attempts to download a POS order receipt for an Indian company, a traceback is raised. Steps to reproduce the error: - Install ``l10n_in_pos`` module with demo data - Switch to IN Company - Open a PoS Session > Create an order > Payment > Validate - Navigate to the backend - Go to Orders > Open the created order > Download Receipt Traceback: ``` QWebError: Error while rendering the template: KeyError: 'l10n_in_hsn_code' Template: point_of_sale.pos_orderline_receipt_information ``` https://github.com/odoo/odoo/blob/9fe02a4585ce139c2ea20e9d282bc92f37b7cad7/addons/point_of_sale/controllers/main.py#L24 Here, ``order_receipt_generate_image`` method is called using the current request environment. As a result, the active company becomes the user's current company instead of the POS order’s company. Because of this mismatch, the condition that adds ``l10n_in_hsn_code`` to the POS data fields (based on the company’s fiscal country) is not satisfied at [1]. Consequently, the field is missing from the receipt line data at [2], and the template raises a KeyError when trying to access it. [1]: https://github.com/odoo/odoo/blob/9fe02a4585ce139c2ea20e9d282bc92f37b7cad7/addons/l10n_in_pos/models/pos_order_line.py#L21-L24 [2]: https://github.com/odoo/odoo/blob/9fe02a4585ce139c2ea20e9d282bc92f37b7cad7/addons/point_of_sale/receipt/pos_order_receipt.py#L76 sentry-7417101015 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes how employee birth dates are read from certain Belgian national identity numbers. Some special “bis” numbers use a shifted month value, and the system now normalizes it correctly so valid dates are not rejected.
Original PR description
The NISS month field can be increased by 20 or 40 for "numéros bis". This caused invalid date parsing. Use modulo 20 to normalize the month before constructing the birthday. task-6144297
This fix ensures that calendar leave entries without a specific resource are no longer ignored. Instead, they are applied across all resources as intended, helping planning and availability stay accurate.
Original PR description
Before this commit, any `Resource Calendar Leave` created with no `Resource` related to it was ignored, while it should have been applied to all `Resources`. This commit makes sure that any `Resource Calendar Leave` with no related `Resource` is applied to all `Resources` as intended. task-5798796 Forward-Port-Of: odoo/enterprise#112575
This change fixes a test setup issue in the electronic invoice export module. It prevents a startup error during automated tests when a security group is checked before its module is fully confirmed as installed, making test runs more reliable.
Original PR description
The `get_default_groups` call happens during super.setUpClass(), therefore we have not checked (yet) if the module in which the security group is in is installed, and we end up with an Exception. task-none Forward-Port-Of: odoo/odoo#260230
Searching for settings on mobile no longer triggers an error. This makes it easier for users to quickly find the right configuration option while using the app on a phone or tablet.
Original PR description
Before this commit, when searching a setting in mobile a error as raised. opw-6140257 Forward-Port-Of: odoo/odoo#260311
This change improves how Odoo checks search filters before they are used. It now catches invalid values, such as text entered where a number is expected, helping prevent errors later in processing and making validation more reliable.
Original PR description
`Domain([('num_field', '=', 'dfd')]).validate(model)` should raise an exception because 'dfd' is not a valid number. Currently, the optimization does not check the data types for all operators, but these are checked during SQL generation. Let's generate the SQL to validate the domain.
task-6132976
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#260102This fix ensures that queries with ordered result IDs still look like they have restrictions when other parts of the system check for them. It preserves existing behavior and prevents related code from misreading these queries as unrestricted.
Original PR description
Some code uses `if query.where_clause` to detect if there are any restrictions on the table. When setting ordered result ids, we simply used a JOIN, so there is no detected where clause. To keep existing code working, we add a dummy 1=1 to the where clause. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260306
This change preserves the visual link styling in frozen and shared spreadsheets while still preventing those links from being clicked on public pages. It matters because dashboards keep their intended layout and appearance without exposing usable internal links.
Original PR description
Since https://github.com/odoo/odoo/pull/166843, we remove the odoo links entirely from the spreadsheet on `freeze and share`. While it is true that the link is not usable from a public page (and that…
Since https://github.com/odoo/odoo/pull/166843, we remove the odoo links entirely from the spreadsheet on `freeze and share`. While it is true that the link is not usable from a public page (and that we'd somehow leak internal views information in the links), cells with links benefit from a specific style that is not hardcoded on the cell but rather computed based on their content. By removing the links from teh cells altogether, the greenish link style is lost on those cells and we actually rely on that style for our dashboards layout. To preserve the intension of https://github.com/odoo/odoo/pull/166843, we introduce a new type of links `neutralized` which allows the cell to be recognized as a link (and benefit from the style) while disabling their behaviour (no click). Task-6063301 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#260250 Forward-Port-Of: odoo/odoo#256357
This update fixes an issue where Adyen payments could fail when capturing or canceling an authorized payment. It also ensures the related transaction record updates correctly, so payment statuses stay accurate after these operations.
Original PR description
Issue 1: --- Capturing/voiding transaction is failing with the error: `The payment provider rejected the request. Original pspReference required for this operation` Steps to reproduce: 1- Setup Adyen…
Issue 1: --- Capturing/voiding transaction is failing with the error: `The payment provider rejected the request. Original pspReference required for this operation` Steps to reproduce: 1- Setup Adyen payment provider. 2- Enable `Capture amount manually`. 3- Create a SO and confirm. 4- Generate a payment link and pay. 5- In SO, capture the full amount. Cause: --- After https://github.com/odoo/odoo/commit/efc2788dfccd13ee6feb309430ff57e49664ff97, in the payment `_void()`/`_capture()`, a child tx is created. However the child tx is missing the `provider_reference` required to send the payment provider. Issue 2: --- The child tx created for capture/void is always remains in draft state. Cause: --- This is reproduced after https://github.com/odoo/odoo/commit/efc2788dfccd13ee6feb309430ff57e49664ff97 which we create a child tx in capture/void. But in `_search_by_reference` which is called by webhook to find the tx, we are returning the source tx. As a result only the state of the source tx is changed. opw-6120846 opw-6120071 Forward-Port-Of: odoo/odoo#259223