Daily updates from Odoo
Wednesday, November 12, 2025
170 changes
13 changes
Enhancements to existing features
This change adds a new exact-match selector option for Hoot tests, making test definitions easier to read and write. It also updates existing tests to use this clearer syntax, improving developer productivity without changing business behavior.
Original PR description
This commit adds the ':text()' pseudo-class to the list of supported pseudo-classes in Hoot selectors. Its purpose is the same as ':contains()', with the specificity of being an *exact* match instead of a *partial* one. It effectively replaces ':contains(/^<expression>$/)' by ':text(<expression>)', improving the readability and making the developer experience a bit nicer. Enterprise: https://github.com/odoo/enterprise/pull/98772 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235107 Forward-Port-Of: odoo/odoo#234331
The test suite now uses a newer text-matching method in places where it behaves more predictably than the previous approach. This helps keep automated checks more stable and easier to maintain, without changing product behavior for users.
Original PR description
This commit replaces all found occurrences where ':contains' (with an exact match regular expression) could be replaced by ':text'. Community: https://github.com/odoo/odoo/pull/234331 Forward-Port-Of: odoo/enterprise#99183 Forward-Port-Of: odoo/enterprise#98772
The POS no longer checks for blackbox driver updates during session opening. If the drivers are outdated, users will still be warned later when they try to use a blackbox feature, which keeps startup smoother without losing the warning.
Original PR description
When introducing the blackbox queue service, we added a check at the opening of the POS to ensure that the blackbox drivers were up to date. This check is done at the start of session opening. It is now not necessary anymore, if the drivers are not up to date, an error will also be shown to the user when they try to use a blackbox functionality. Forward-Port-Of: odoo/enterprise#99014
Resolved issues and error corrections
This fix brings back the save button and the related trusted-order behavior in Point of Sale. It restores the intended workflow so trusted terminals can continue handling orders correctly, preventing missing functionality for affected users.
Original PR description
The button save and all the logic about trusted orders were removed. This commit puts it back. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#229335 Forward-Port-Of: odoo/odoo#200567
This update corrects how job listings are counted and shown to visitors based on their location, even when they are not logged in. It also fixes an issue where duplicate location results could lead to incorrect counts being displayed, improving the accuracy of job search and redirection behavior.
Original PR description
This commit fixes 2 bugs: When you are not logged in and geolocalized, we don't redirect the visitor to the right country because the visitor cannot read hr.job, so the count will always be 0. Now we use sudo to have the count whether you are logged in or not. Another bug is in compute_filter_selection_counters: in case you provide a key_getter that is not the same as the grouping_field, when we count, we only keep the last count in case of duplicates. Eg, if you group by address_id and count the address_id.country_id, you will get the count of hr.job open in the last office you iterate over. Forward-Port-Of: odoo/odoo#234713
This update prevents an unexpected scrollbar from appearing in the website editor when hidden text is used inside certain content blocks. It improves the editing experience in Chrome, Edge, and Safari by keeping the page layout stable and avoiding a distracting visual issue.
Original PR description
This is a known issue [1] in bootstrap, which displays an unexpected scrollbar when we have a visually-hidden text in the table. The issue occurs in Chrome, Edge and Safari, but does not in Firefox. **Steps to see the issue:** - Open website and start editing - Drop a table of content - Drop inside of the ToC a donation snippet - Click on the donation amounts form => A scrollbar appears. The visually-hidden spans are present since [2], but the problem couldn't be seen until commit [3] removed the `overflow: hidden` style. [1]: https://github.com/twbs/bootstrap/issues/41554 [2]: https://github.com/odoo/odoo/commit/faafb913a0af5c4bfa7d207e09bbea0d97125aed [3]: https://github.com/odoo/odoo/commit/10156c10b09dc502a40253d64e2505e817a520bf task-5169275
This change prevents an access error that could appear when a purchase order uses an unrestricted analytic account shared across companies. It ensures users only see budget lines they are allowed to access, avoiding interruptions when entering purchase orders.
Original PR description
Steps to reproduce: - Create an analytic account [ACCOUNT] not restricted to any company - Create an analytical distribution model applying [ACCOUNT] to [PRODUCT] not restricted to any company - Create a budget in company [COMP A] using analytic account [ACCOUNT] - Create a budget in company [COMP B] using analytic account [ACCOUNT] - In company [COMP B], create a purchase order, add [PRODUCT] to a line Issue: Access Error is raised Analysis: Because we search with sudo company rules are bypassed and the system assign both budget lines to the order line (budget_line_ids). When we access the field, the system try to access the budget line of the other company, causing the error. As solution we revert https://github.com/odoo-dev/enterprise/commit/4941c1928c9a2bcb38af3cadf023f904c9fd9be0 removing the `sudo` on the search and we explicitly check if the user has read access on the budget analytic model opw-5056712 Forward-Port-Of: odoo/enterprise#98573
This change stops event ticket products from being changed into a rental setup, which could break the online registration and payment flow. It helps ensure attendees can always complete booking and payment for event tickets without errors.
Original PR description
Steps ----- 1. Have `sale_renting` but not `sale_stock_renting` installed; 2. create an event with a ticket; 3. make the ticket's product rentable; 4. change ticket's product type to Goods; 5. publish the event to website; 6. register for the event via website; 7. go to payment. Issue ----- > AttributeError: 'bool' object has no attribute 'tzinfo' Cause ----- By making it a rental product, it creates a rental order, but as registering for an event via website doesn't have any way to add rental dates, rental lines cannot be processed & rendered as expected. Solution -------- Prevent users from changing the `service_tracking` away from `'event'` by adding an `api.constrains` to `product.product` on `service_tracking` and `event_ticket_ids`. opw-5207045 Forward-Port-Of: odoo/odoo#234705
This fix restores automatic cost updates on sale order lines after an order has been confirmed, canceled, and then reset to draft. It matters because sales margins and pricing can now reflect the correct purchase cost again, even after order status changes.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Have a product with a purchase cost; 2. have sale margins enabled; 3. add a the product to a quotation; 4. change pricelist to one with a different currency; 5. note that the line's cost gets updated; 6. change order state to confirmed, then canceled, then back to draft; 7. change pricelist again. Issue ----- The purchase cost no longer update. Cause ----- The `_compute_purchase_price` override in `sale_stock_margin` doesn't pass the line to `super` if it `has_valued_move_ids`. This hook only checks for the existence of linked `move_ids` on the record with no regard for their state. Solution -------- 1. Move the `has_valued_move_ids` hook from `sale` to `sale_stock`. 2. Only return `True` if any of the moves aren't in draft or canceled. opw-5147321 Forward-Port-Of: odoo/odoo#233746
This change prevents the website editor from crashing when a user presses Delete without an active text selection. It improves stability during common editing actions, especially when working with embedded content like videos and snippets.
Original PR description
If the selection of the document is not set and the user presses the delete key, the delete handler of the list plugin throws an error. Steps to reproduce (in 19.0, where the issue was discovered): - Open website builder - Drop the video inner snippet in the header - Double-click & drag from the video to just outside the video - Click once on the video - Press "delete" - Bug: Traceback task-5186954 Forward-Port-Of: odoo/odoo#232643
The website now publishes product price information in a way that matches the shop’s tax display setting. This prevents search engines and other consumers of the page markup from seeing a different price than visitors see on the website.
Original PR description
## Version
18.2+
SEO Schema refactoring from task-3866937
## Issue
The markup always contains the price without taxes, no matter the website settings for pricing display (with or without taxes).
## Steps to reproduce
- Go to Website settings:
- Choose "Taxes Included" for "Display Product Prices".
- Got to the shop and select any product on which taxes apply (e.g. Customizable Desk):
- Open console and execute `JSON.parse(document.querySelectorAll('[type="application/ld+json"]')[1].innerHTML)[0]['hasVariant'][0]['offers']['price']`;
- The found price and the displayed price (visible on the page) are different
## Fix
Allow tax inclusion based on parameter to mimic template's behavior on variants too depending on the website.
https://github.com/odoo/odoo/blob/52a6d88a188d5456262428847aed229f117da8ed/addons/website_sale/models/product_template.py#L377-L430
opw-4923780
Forward-Port-Of: odoo/odoo#235106
Forward-Port-Of: odoo/odoo#225577This change cleans up a complex styling workaround in the spreadsheet side panels. It keeps the same visual result while making the interface easier to maintain and less prone to styling conflicts in the future.
Original PR description
Because of a really strong rule in o_spreadsheet lib that forced the box-sizing property pretty much everywhere, we came up with a super dense rule to counteract it inside odoo and specifically inside the side panels. This commits aims to simplify it at best with the common denominator of those rules. Task-4878174 Forward-Port-Of: odoo/enterprise#99240 Forward-Port-Of: odoo/enterprise#98876
This update fixes spreadsheet input styling so missing or invalid fields are always clearly marked. It also prevents dark mode styling from altering the spreadsheet layout, keeping the interface consistent and easier to use.
Original PR description
Following the style revamp of the o-spreadsheet lib, we introduced a class o-input (differs from odoo o_input) in order to avoid collision with the odoo classes which tend to be altered in dark mode which spreadsheet does not support. However, we still relied on the default behaviour of odoo classes to mark specific inputs as invalid or missing. This commit ensures that missing/invalid are always marked as such while make preventing the dark mode to break the default layout. Task-4878174 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#235236 Forward-Port-Of: odoo/odoo#234517
9 changes
Enhancements to existing features
The point of sale now shows clear error messages when the fiscal device is disconnected or when the social security number is missing. It also tells users what to do next, which should reduce confusion and help staff resolve issues faster.
Original PR description
We now display an error when the FDM is disconnected, or when the user needs to fill in the social security number. We also advise what to do in such cases.
Resolved issues and error corrections
This fix prevents the point of sale from raising an error when a pro forma request finishes after the related order has already been deleted. It checks that the order still exists before using it, which avoids interruptions for users and keeps the flow stable.
Original PR description
Before this commit, when trying to send a pro forma for an order that had been deleted while the pro forma call was in the queue, a JS error would occur because the callback of the call would try to access the order which was no longer existing in the frontend. This is now fixed by checking that the order is still present before accessing it in the callback.
The website editor now correctly displays overlay borders and snippet options when the site uses a right-to-left language such as Arabic. This prevents the editing tools from appearing misplaced or hidden, improving the experience for teams managing multilingual websites.
Original PR description
__Before this commit__: 1. Set a right-to-left language (e.g. arabic) as default language on the website 2. Open the website editor 3. Select an element of the page => The editor overlay border are…
__Before this commit__: 1. Set a right-to-left language (e.g. arabic) as default language on the website 2. Open the website editor 3. Select an element of the page => The editor overlay border are not in the correct place 4. Open the snippet dialog => The snippets are not visible. __Cause__: Since [this commit][1], `lang` in `session.bundle_params` is (correctly) set to the `request.lang.code`. Consequently, `website.assets_all_wysiwyg_inside` is fetched with the frontend language code in the `searchParams` which shouldn't be the case especially if the website language direction is not the same as the backend one. __Description of the fix:__ The `getBundle` method from outside the iframe is used instead of the frontend one to retrieve the URL of the bundle that matches the language direction of the builder. Backport and adapt the test from [this commit][2]. [1]: https://github.com/odoo/odoo/commit/e10852a45f10c55a833c33a51956e5f [2]: https://github.com/odoo/odoo/commit/7bcd56c07852b77849b05184200c48a task-5246916 opw-5214703 Forward-Port-Of: odoo/odoo#234991 Forward-Port-Of: odoo/odoo#234782
This fix stops event ticket products from being changed into a product setup that breaks online registration and checkout. It ensures tickets keep the right tracking rules, so customers can register for events and complete payment without errors.
Original PR description
Steps ----- 1. Have `sale_renting` but not `sale_stock_renting` installed; 2. create an event with a ticket; 3. make the ticket's product rentable; 4. change ticket's product type to Goods; 5. publish the event to website; 6. register for the event via website; 7. go to payment. Issue ----- > AttributeError: 'bool' object has no attribute 'tzinfo' Cause ----- By making it a rental product, it creates a rental order, but as registering for an event via website doesn't have any way to add rental dates, rental lines cannot be processed & rendered as expected. Solution -------- Prevent users from changing the `service_tracking` away from `'event'` by adding an `api.constrains` to `product.product` on `service_tracking` and `event_ticket_ids`. opw-5207045 Forward-Port-Of: odoo/odoo#234705
This update removes leftover unused code from the reconciliation model after a previous redesign. It does not change how users work, but it keeps the codebase cleaner and easier to maintain.
Original PR description
In the PR (odoo/enterprise#80787) the reconciliation model was refactored in order to be easier to use for users. However, some dead code was forgotten and not removed.
This change prevents an access error that could occur when creating a purchase order in a company that shares an unrestricted analytic account with another company. It ensures budget information is checked safely so users only see budget lines they are allowed to access, avoiding interruptions during purchasing.
Original PR description
Steps to reproduce: - Create an analytic account [ACCOUNT] not restricted to any company - Create an analytical distribution model applying [ACCOUNT] to [PRODUCT] not restricted to any company - Create a budget in company [COMP A] using analytic account [ACCOUNT] - Create a budget in company [COMP B] using analytic account [ACCOUNT] - In company [COMP B], create a purchase order, add [PRODUCT] to a line Issue: Access Error is raised Analysis: Because we search with sudo company rules are bypassed and the system assign both budget lines to the order line (budget_line_ids). When we access the field, the system try to access the budget line of the other company, causing the error. As solution we revert https://github.com/odoo-dev/enterprise/commit/4941c1928c9a2bcb38af3cadf023f904c9fd9be0 removing the `sudo` on the search and we explicitly check if the user has read access on the budget analytic model opw-5056712 Forward-Port-Of: odoo/enterprise#98573
Sales order lines now correctly refresh their cost after an order has been canceled and set back to draft. This prevents outdated margin and pricing information from sticking around when the pricelist or currency changes.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Have a product with a purchase cost; 2. have sale margins enabled; 3. add a the product to a quotation; 4. change pricelist to one with a different currency; 5. note that the line's cost gets updated; 6. change order state to confirmed, then canceled, then back to draft; 7. change pricelist again. Issue ----- The purchase cost no longer update. Cause ----- The `_compute_purchase_price` override in `sale_stock_margin` doesn't pass the line to `super` if it `has_valued_move_ids`. This hook only checks for the existence of linked `move_ids` on the record with no regard for their state. Solution -------- 1. Move the `has_valued_move_ids` hook from `sale` to `sale_stock`. 2. Only return `True` if any of the moves aren't in draft or canceled. opw-5147321 Forward-Port-Of: odoo/odoo#233746
This update corrects how spreadsheet form fields are displayed so missing or invalid values are clearly marked again. It also prevents dark mode styling from interfering with the spreadsheet’s default layout, helping keep the interface consistent and readable.
Original PR description
Following the style revamp of the o-spreadsheet lib, we introduced a class o-input (differs from odoo o_input) in order to avoid collision with the odoo classes which tend to be altered in dark mode which spreadsheet does not support. However, we still relied on the default behaviour of odoo classes to mark specific inputs as invalid or missing. This commit ensures that missing/invalid are always marked as such while make preventing the dark mode to break the default layout. Task-4878174 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#235236 Forward-Port-Of: odoo/odoo#234517
This change cleans up a complicated visual styling rule in the spreadsheet side panels. It makes the stylesheet easier to maintain while keeping the same behavior for users.
Original PR description
Because of a really strong rule in o_spreadsheet lib that forced the box-sizing property pretty much everywhere, we came up with a super dense rule to counteract it inside odoo and specifically inside the side panels. This commits aims to simplify it at best with the common denominator of those rules. Task-4878174 Forward-Port-Of: odoo/enterprise#99240 Forward-Port-Of: odoo/enterprise#98876
2 changes
Resolved issues and error corrections
This change fixes how subscription quantities are updated when an invoice is only partially credited. After the fix, the remaining invoiced quantity stays accurate instead of dropping to zero, which helps keep subscription billing records correct.
Original PR description
**Issue** When creating a partial credit note (i.e., for a quantity less than originally invoiced) for a subscription invoice, the `qty_invoiced` on the corresponding subscription order line is…
**Issue** When creating a partial credit note (i.e., for a quantity less than originally invoiced) for a subscription invoice, the `qty_invoiced` on the corresponding subscription order line is incorrectly set to zero, instead of reflecting the remaining quantity. **Steps to Reproduce** 1. Create a subscription with a quantity of 50. 2. Confirm the subscription and generate an invoice. 3. Create a credit note (reversal) for the invoice. 4. Change the credited quantity to 30. 5. Post the credit note. 6. The subscription order line shows qty_invoiced = 0 instead of the expected 20. **Root Cause** The method `_get_max_invoiced_date()` is used to determine the latest invoiced period for a subscription. In its original implementation, it removes refunded periods from the list of invoice dates regardless of whether the refund is partial or full. This causes the system to consider the period as not invoiced at all, which leads to incorrect recomputation of `qty_invoiced` **Fix** Adjust `_get_max_invoiced_date()` to track the net invoiced quantity per period. A period is only removed from the list of invoice dates if it has been fully refunded (i.e., net quantity is zero). This ensures that partially refunded periods are still considered invoiced, and the `qty_invoiced` is correctly updated to reflect the remaining quantity Opw-4908760 Forward-Port-Of: odoo/enterprise#91344
This change prevents an access error that could appear when using the same unrestricted analytic account across multiple companies. It ensures purchase orders only check budget information the current user is allowed to read, avoiding interruptions for users working in company-specific budgets.
Original PR description
Steps to reproduce: - Create an analytic account [ACCOUNT] not restricted to any company - Create an analytical distribution model applying [ACCOUNT] to [PRODUCT] not restricted to any company - Create a budget in company [COMP A] using analytic account [ACCOUNT] - Create a budget in company [COMP B] using analytic account [ACCOUNT] - In company [COMP B], create a purchase order, add [PRODUCT] to a line Issue: Access Error is raised Analysis: Because we search with sudo company rules are bypassed and the system assign both budget lines to the order line (budget_line_ids). When we access the field, the system try to access the budget line of the other company, causing the error. As solution we revert https://github.com/odoo-dev/enterprise/commit/4941c1928c9a2bcb38af3cadf023f904c9fd9be0 removing the `sudo` on the search and we explicitly check if the user has read access on the budget analytic model opw-5056712 Forward-Port-Of: odoo/enterprise#98573
23 changes
Enhancements to existing features
This update speeds up how tax returns are generated and refreshed, making the related accounting screens and setup wizard respond faster. It also fixes a case where manually created draft returns could be incorrectly removed before being posted.
Original PR description
- batched _compute_company_ids on returns - batched return to unlink in _generate_or_refresh_all_returns - removed redondant call to _generate_or_refresh_all_returns in…
- batched _compute_company_ids on returns - batched return to unlink in _generate_or_refresh_all_returns - removed redondant call to _generate_or_refresh_all_returns in action_save_onboarding_fiscal_year since we want to call it only when a value is changed and that's already handled in the write on the company. - batched _is_available_for on reports - make only one write on the company (and one call to _generate_or_refresh_all_returns) when writing or create the fiscal year wizard. - dont delete return created manually with a date before the date of the account_opening_date and not yet posted. Detected from runbot error: https://runbot.odoo.com/odoo/runbot.build.error/231463 A small workaround is needed on the company when writing the changes from the fiscal year wizard. This is because related fields are writen one by one, which then trigger multiple times _generate_or_refresh_all_returns. To prevent this, we are batching all the write on the company from the fiscal year wizard in one write. The opening_date need to be handled separatly since it's not a related field but still need to be writen on the company, if removed from the vals during the create it's then not possible to save the wizard anymore. Also fixed a bug where the returns manually created before the account_opening_date would be deleted if they were not posted before the next call to _try_create_returns_for_fiscal_year. **Detailed Explanation** We can see the tour being broken when trying to save on the wizard: <img width="1366" height="768" alt="image" src="https://github.com/user-attachments/assets/9443251c-aee1-4fbe-be2f-27c11bcbb77d" /> So we can do a flamegraph to take a look at what's happening on that database during that time and we can see 2 majors time uses, a call to `_generate_or_refresh_all_returns` triggered by a write on the wizard and a call to `action_save_onboarding_fiscal_year` <img width="1396" height="855" alt="image" src="https://github.com/user-attachments/assets/a9d310da-2787-4806-951d-e50b8c1da2a8" /> The first call to `_generate_or_refresh_all_returns` took about 7.8s, the second one took about 1.1s First, we can see a lot of `_compute_company_ids` calls, this is because we have `precompute=True` on this field due to it being needed in the different access rules. Since all the returns that are created have similar main company, tax unit and return type, we can easily batch them to only call `_get_company_ids` once for all the returns that will be created. Resulting in the following flamegraph: <img width="1422" height="866" alt="image" src="https://github.com/user-attachments/assets/c52c88c7-0263-44fb-a16c-52456673dc92" /> The first call to `_generate_or_refresh_all_returns` took about 0.8s, the second one took about 1.2s Another little change we can do is to remove the call to `_generate_or_refresh_all_returns` during `action_save_onboarding_fiscal_year` and adding the forced_date from the first one to the second one. <img width="1294" height="844" alt="image" src="https://github.com/user-attachments/assets/7ad55d06-ecd4-4957-b514-71fffa6de00c" /> We now end up with one call to `_generate_or_refresh_all_returns` that takes 1.4s BUT, we can still do better. We can see that all we did previously was only do to one thing less. The "real" problem was the many search calls done in `_is_available_for` during the `_init_options_variants`. <img width="1268" height="693" alt="image" src="https://github.com/user-attachments/assets/ebae398d-dfdd-4c1e-99ac-44f25e5875e7" /> After the final change, we are down to 0.9s ! One thing to keep in mind, all those flamegraph were done on a dump of a database from a nightly test, which had many companies created as well as **every** modules installed, which means every return types, reports, ... This means those performance improvements wont be as useful on small databases.
The Swiss QR payment code now uses the updated structured address format for both creditor and debtor information. This change aligns Odoo with the current Swiss QR standard and helps ensure payments continue to be generated correctly.
Original PR description
Change creditor's and debtor's address to a structured format of type S. Old type K is discontinued. Port of odoo/odoo#232083 with additional tests. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The POS no longer checks blackbox driver updates during session opening. If the drivers are outdated, users will now see the error only when they try to use a blackbox feature, which removes an unnecessary step at startup and keeps opening faster.
Original PR description
When introducing the blackbox queue service, we added a check at the opening of the POS to ensure that the blackbox drivers were up to date. This check is done at the start of session opening. It is now not necessary anymore, if the drivers are not up to date, an error will also be shown to the user when they try to use a blackbox functionality. Forward-Port-Of: odoo/enterprise#99014
Resolved issues and error corrections
This change fixes an error that could happen when users tried to edit certain website pages, such as appointments pages. It improves the editing experience by preventing the editor from crashing on text elements, so pages can be opened and edited normally.
Original PR description
To reproduce: ============= - with website appointments installed go to appointments page - try to edit the page -> error Problem: ======== when entering edit mode, we call `selection_blocker_predicates` on editable nodes which will call `node.hasAttribute` internally. However, some nodes are text nodes and thus do not have this method, leading to an error. Solution: ========= `isBlock` method checks several things on the node, including if it's a text node. so swapping the order of the conditions will fix the problem. opw-5239754 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Uploading an invalid or encrypted PDF in Sign no longer causes an error screen. The system now checks the file first and safely rejects unreadable documents, improving reliability for users working with signed documents and templates.
Original PR description
Currently, an error occurs when trying to upload an encrypted/invalid document in the Sign Documents. **Steps to reproduce:** 1. Install **Sign** module. 2. Try to upload the encrypted PDF in Sign Document or templates. **Sample files:** https://drive.google.com/drive/folders/1MkiFRgJOlv2zc6ZW3SJYnMwHZYy9CFtX?usp=drive_link **Errors:** ``` DependencyError - PyCryptodome is required for AES algorithm UnicodeDecodeError - 'utf-8' codec can't decode byte 0xa4 in position 0: invalid start byte ``` **Cause:** The `flatten_pdf` function calls `PdfFileReader`, which raises an error if the file is encrypted or cannot be read/decrypted properly. Also, adding AES encrypted document in already uploaded valid document will triggers the same error. **Fix:** This commit prevents a traceback when uploading invalid or encrypted PDF files by validating the PDF data beforehand. sentry-6913657420
This fix ensures the customer document fields appear or disappear correctly when an invoice is moved between journals that do or do not use documents. It prevents users from seeing the wrong fields after changing the journal, which helps avoid confusion and saving errors.
Original PR description
**Steps to reproduce:** 1. Install `l10n_ar` localization. 2. Create two sales journals with the `Use documents` option enabled and disabled. 3. Create an invoice and add a customer and change the…
**Steps to reproduce:**
1. Install `l10n_ar` localization.
2. Create two sales journals with the `Use documents` option enabled and disabled.
3. Create an invoice and add a customer and change the journal to with `use documents` and save the record
4. Now change the jornal to without `use documents` and try to save it
**Observed behavior:**
The `Document Type` and `Document Number` fields fail to show or hide properly when switching between journals with different `Use documents` configurations.
**Cause:**
The `_compute_l10n_latam_use_documents` method lacked the `@api.depends` decorator with appropriate dependencies. As a result, when the journal is changed on an invoice, the
`l10n_latam_use_documents` field was not recomputed, leading to incorrect visibility of related fields.
**Fix:**
Add the missing `@api.depends('journal_id.l10n_latam_use_documents', 'move_type')` decorator to ensure the field recomputes whenever the journal or its `Use documents` setting changes.
opw-5220202This fix ensures that journals excluded from a Multi-Ledger remain excluded even after they are archived. As a result, financial reports such as Profit and Loss will no longer include entries from journals that were meant to be left out.
Original PR description
A journal is still excluded from the ledger even if it is archived. To reproduce: * create a new journal * create a journal entry impacting the P&L in that journal * create a Multi-Ledger (journal group) excluding this journal * archive the journal * open the P&L The journal entry is impacting the report, because the journal is not excluded. task-5251383
This update fixes how tax return reports are handled when a country has more than one report type. It prevents duplicate or incorrect return content by ensuring each closing entry uses only the relevant tax data, and it adjusts some reports so they no longer generate an unnecessary closing entry.
Original PR description
It's possible for different tax reports to exist in the same country, each with its own return type. However, this is an issue when they aren't configured to generate closing entries with distinct contents, since each of them will then repeat the content of the other. To fix this, when it's legitimate to make multiple closing entries, we make sure the closing entry only considers the tax move lines linked to the report's tax tags. If multiple reports must generate the same closing entry (typically because one of them is a simplified version of the other), we disable the generation of the return for one of them. Some reports also didn't need to generate a closing entry and were switched to a 'review_submit' state. task-5123564 Forward-Port-Of: odoo/enterprise#98973 Forward-Port-Of: odoo/enterprise#98158
Pivots inserted into spreadsheets now keep the same date-based sorting as in the web pivot view. This fixes an issue where date and date-time columns could lose their order because their values were not normalized correctly.
Original PR description
If on the web pivot view we create a pivot with a date/dateTime field in the columns, and sort on one of these columns, the resulting pivot when inserted in a spreadsheet isn't sorted. This was because we didn't normalize the date values in the pivot `sortedColumn`, and we had UTC timestamps `2023-01-01 00:00:00` instead of normalized values `01/2023`. Task: [3575465](https://www.odoo.com/web#id=3575465&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#99203 Forward-Port-Of: odoo/enterprise#96508
Follow-up reminder emails now keep the invoice attachment when invoices are set to be included. This fixes an issue where the system was accidentally hiding those attachments, so customers receive the full reminder message with the invoice included.
Original PR description
### Issue: The invoices supposed to be sent with follow-ups when the option `join_invoices` is tick are not sent. ### Steps to reproduce: - Install "account_followup" - Create a new partner - Create…
### Issue: The invoices supposed to be sent with follow-ups when the option `join_invoices` is tick are not sent. ### Steps to reproduce: - Install "account_followup" - Create a new partner - Create an invoice for this partner with a due date in the past, confirm and send - Go on the partner form view, under the "Accounting" it should be in the state "In need of action" - Click "Send", the wizard pops up with the invoice attachment - Click "Send", the message does have the invoice attachment, only the report ### Cause: The attachment in linked to the wizard in database but when doing a read, the domain is appended with `'res_field', '=', False` by these lines: https://github.com/odoo/odoo/blob/f8f72b15598576f5870e49879e96fc5c127a6100/odoo/addons/base/models/ir_attachment.py#L598-L603 But the invoices attachments have res_field set to `invoice_pdf_report_file` so they are filtered out. The purpose of adding the new leaf to the domain is to filter out attachments that we are not searching for specifically. As they are linked to a specific field (`res_field`), if we don't search on this field, we are not supposed to see them. With the `followup_manual_reminder` wizard, we are linking attachments having a `res_field` to `account_move.invoice_pdf_report_file` to a new field: `followup_manual_reminder.attachment_ids`. So `'res_field', '=', False` should not be added. ### Solution: The problematic fields are all `Many2Many` fields to `ir.attachment` and since [this commit](https://github.com/odoo/enterprise/commit/fd4fcb1bd8764dbde1c8b3295623dd020c882a60) these fields have `bypass_search_access=True`. So the fix consist of not adding the domain `'res_field', '=', False` when `bypass_access` is True. opw-5164456
Live chat on mobile devices now keeps the message field at a readable size without triggering the browser’s automatic zoom. This prevents the send button from being hidden and makes it easier for visitors to type and send messages smoothly.
Original PR description
Before this commit, when using livechat for visitors on mobile devices, click on input would zoom on input of about 115%. This zoom would hide send button at the very end of composer input, and would…
Before this commit, when using livechat for visitors on mobile devices, click on input would zoom on input of about 115%. This zoom would hide send button at the very end of composer input, and would force users to pinch-to-unzoom, making the UX quite poor. This problem happens because mobile devices have an auto-zoom feature that is triggered when font-size is below 16px. The discuss UI is designed with 14px font size (web client font size), and since 14px < 16px, it zooms on input focus to about 115%. This commit fixes the issue by using a font-size of 16px specifically for livechat visitor on mobile devices, so that this doesn't auto-zoom. Note that this problem doesn't happen on the web client even though this uses a font-size of 14px because it specifically disable the autozoom feature: https://github.com/odoo/odoo/blob/17.0/addons/web/views/webclient_templates.xml#L250 This solution is not practical for livechat, for which it has to work on any external website. opw-5229076 Before <img width="199" height="431" alt="after" src="https://github.com/user-attachments/assets/cc2f8e04-bde7-4eeb-84d5-b2efa2763490" /> After <img width="199" height="431" alt="before" src="https://github.com/user-attachments/assets/6c6679fc-9c16-40e7-ab6f-21540d20d59d" /> Forward-Port-Of: odoo/odoo#235182 Forward-Port-Of: odoo/odoo#234967
The website editor could crash when users tried to edit the appointment booking page. This update prevents the error by handling non-page elements safely, so editing the page works normally again.
Original PR description
**Steps to reproduce:** - Install website_appointment_sale with demo data - Start booking an appointment and stop at the `Date & Time` selection page - Open the `website editor` and click the `edit`…
**Steps to reproduce:**
- Install website_appointment_sale with demo data
- Start booking an appointment and stop at the `Date & Time` selection page
- Open the `website editor` and click the `edit` option
- A traceback occurs
**Issue:**
- A traceback occurs when trying to edit the page,
Error:
`TypeError: blocker.hasAttribute is not a function
at selection_blocker_predicates`
**Cause:**
- The `selection_blocker_predicates` function assumed every `blocker` was an Element
and called `blocker.hasAttribute(...)`. When a non-element node (text, comment, or object)
was encountered, the call raised a 'TypeError'.
<img width="778" height="177" alt="image" src="https://github.com/user-attachments/assets/7ef14d01-56e0-45b7-a39e-3e9fb6a4c6ce" />
> nodeType = 3 then it’s a `text node`
https://github.com/odoo/odoo/blob/700fac2532d2de6abc6f87e30a5b056dcfc109d1/addons/html_editor/static/src/main/selection_placeholder_plugin.js#L39-L45
**Solution:**
- Make the function defensive by checking that `blocker` is an instance of `Element`
- before accessing DOM methods. Non-element nodes are now safely check.
---
opw : 5241222
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fix makes sure POS invoice lines are properly included in the HSN validation used for the GSTR-1 report. As a result, items missing an HSN code are more reliably flagged, while older POS lines that lack unit details stay out of the check.
Original PR description
Previously, POS move lines from the original POS entries were not considered during the HSN validation in the GSTR-1 report. As a result, lines without an HSN code were incorrectly skipped from the warning check. This commit updates the domain logic to ensure that: - POS move lines with a Unit of Measure (UoM) but without an HSN code are now included in the check. - Older POS lines without a UoM remain excluded from validation. opw-5252620
This fix prevents employees from seeing appraisal goals they should not have access to. It closes a visibility gap so only the appropriate people can view each goal, helping protect sensitive performance information.
Original PR description
Step to reproduce:
-------------------
1- Log as Mitchell Admin
2- Create a goal for an employee which is not one of Marc Demo
subordinnates and don't put him as goal's manager
3- Log As Marc Demo
You will see this goal.
You are not supposed to be able to see this goal.This change lets employees and other users read work entries even if they are not attendance managers. It removes an access-rights error that could block normal viewing of work entry information, improving day-to-day usability.
Original PR description
When we try to read the work entries, we've got an access rights error if we are not attendance manager. As we are still supposed to read the work entries, we get the attendance interval in sudo --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a test issue in the HR module that could cause build failures when some employee fields were not available on a record. It now safely skips fields that cannot be accessed, preventing unnecessary crashes during automated checks.
Original PR description
This test had a bug: `self.env['hr.employee']._fields.keys()` may contain fields that do not exist in an `hr.employee` record. Now, employee fields that cannot be accessed are filtered out using `hasattr()`. To avoid further crashes. Runbot build error: https://runbot.odoo.com/odoo/runbot.build.error/233942 Bug has been introduced by task-5103739 task-5254322 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235158
The fiscal year setup wizard now correctly applies changes to the company even when the wizard starts with default values. This reduces the risk of duplicate updates and makes the setup flow more reliable in more scenarios.
Original PR description
When writing value with the wizard, we wrote the value of related field of the company to prevent multiple write from happening. Now, we handle the write too in case the wizard is created with default value instead of created beforehand. It's also now possible to specify the fields that are to be written to handle more cases in overrides. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change prevents Spreadsheet from crashing when freezing or sharing a view that includes a boolean global filter. It ensures Excel exports handle empty filter values safely, improving reliability for users working with shared spreadsheets.
Original PR description
The method `getFilterDisplayValue` would not handled `undefined` values for boolean global filters, causing crashes when exporting to Excel. Task: [5188932](https://www.odoo.com/web#id=5188932&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) 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#235123 Forward-Port-Of: odoo/odoo#232784
This change makes an automated live chat test more reliable by checking that the background service was actually triggered, instead of waiting a fixed amount of time. It reduces false failures in slow or busy environments without changing how live chat works for users.
Original PR description
The `test_bus_not_started` test ensures the live chat only starts the bus/worker service when needed (i.e. when the customer starts to chat). This is done to ensure we do not waste any server…
The `test_bus_not_started` test ensures the live chat only starts the bus/worker service when needed (i.e. when the customer starts to chat). This is done to ensure we do not waste any server resources. However, this test waits 1 second to see if the worker/bus has started, which is not always enough: the shared worker script needs to be fetched, the worker service proceeds to an initial handshake to ensure the worker is properly started, and the bus ervice initializes by sending an initial request to the worker as well. All those steps can take time, especially when the CPU is bloated and/or the network is slow. This worker/bus service only has one entry method: `bus_service@start`, `worker_service.ensureWorkerStarted`. Instead of waiting for those async operations to complete, the test now checks whether those methods were called. fixes runbot-233814 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 fix ensures the product cost on sales order lines can be updated again after an order has been confirmed, canceled, and reset to draft. It matters because cost and margin calculations will stay accurate when users revisit and adjust a quotation.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Have a product with a purchase cost; 2. have sale margins enabled; 3. add a the product to a quotation; 4. change pricelist to one with a different currency; 5. note that the line's cost gets updated; 6. change order state to confirmed, then canceled, then back to draft; 7. change pricelist again. Issue ----- The purchase cost no longer update. Cause ----- The `_compute_purchase_price` override in `sale_stock_margin` doesn't pass the line to `super` if it `has_valued_move_ids`. This hook only checks for the existence of linked `move_ids` on the record with no regard for their state. Solution -------- 1. Move the `has_valued_move_ids` hook from `sale` to `sale_stock`. 2. Only return `True` if any of the moves aren't in draft or canceled. opw-5147321 Forward-Port-Of: odoo/odoo#233746
This update fixes an issue that prevented PIN codes from being encoded correctly in the Belgian POS blackbox flow. It also improves error handling so the system reacts more reliably when an operation fails or succeeds after being queued.
Original PR description
Since the introduction of the queue mechanism in blackbox, the PIN encoding was not working. This was due to the fact that the blackbox driver trying to access some non-existing data. This is now solved and improved to better handle the error and subsequent error or success. Forward-Port-Of: odoo/enterprise#99029
This change stops event ticket products from being switched into a rental setup that the event website flow cannot handle. It prevents a checkout error during event registration and keeps tickets working correctly for customers.
Original PR description
Steps ----- 1. Have `sale_renting` but not `sale_stock_renting` installed; 2. create an event with a ticket; 3. make the ticket's product rentable; 4. change ticket's product type to Goods; 5. publish the event to website; 6. register for the event via website; 7. go to payment. Issue ----- > AttributeError: 'bool' object has no attribute 'tzinfo' Cause ----- By making it a rental product, it creates a rental order, but as registering for an event via website doesn't have any way to add rental dates, rental lines cannot be processed & rendered as expected. Solution -------- Prevent users from changing the `service_tracking` away from `'event'` by adding an `api.constrains` to `product.product` on `service_tracking` and `event_ticket_ids`. opw-5207045 Forward-Port-Of: odoo/odoo#234705
This change prevents an access error that could appear when using an unrestricted analytic account across multiple companies. Purchase orders now handle budget-related data more safely, so users in one company won’t be blocked by budget records from another company.
Original PR description
Steps to reproduce: - Create an analytic account [ACCOUNT] not restricted to any company - Create an analytical distribution model applying [ACCOUNT] to [PRODUCT] not restricted to any company - Create a budget in company [COMP A] using analytic account [ACCOUNT] - Create a budget in company [COMP B] using analytic account [ACCOUNT] - In company [COMP B], create a purchase order, add [PRODUCT] to a line Issue: Access Error is raised Analysis: Because we search with sudo company rules are bypassed and the system assign both budget lines to the order line (budget_line_ids). When we access the field, the system try to access the budget line of the other company, causing the error. As solution we revert https://github.com/odoo-dev/enterprise/commit/4941c1928c9a2bcb38af3cadf023f904c9fd9be0 removing the `sudo` on the search and we explicitly check if the user has read access on the budget analytic model opw-5056712 Forward-Port-Of: odoo/enterprise#98573
20 changes
New functionality added to Odoo
This update adds the French “Plan Comptable Associatif” as an available chart of accounts in Odoo. It means French nonprofit organizations can now use the standard accounting structure they need for their bookkeeping and financial reporting.
Original PR description
## Description of the issue/feature this PR addresses: Add the French "Plan Comptable Associatif" to the available charts of accounts Reference: https://www.associations.gouv.fr/le-nouveau-plan-comptable-applicable-depuis-le-1er-janvier-2020.html ## Current behavior before PR: ## Desired behavior after PR is merged: French NPOs are allowed to use Odoo for their accounting work. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Enhancements to existing features
This change makes finishing manufacturing work orders much faster by removing repeated calculations and duplicate database updates. It improves reliability for large batches of work orders and helps avoid slowdowns or memory issues when many records are processed at once.
Original PR description
- The `button_finish` method contained a variable intended to filter out moves whose `operation_id` matched the `operation_id` of the entire recordset of work orders passed to the function. However,…
- The `button_finish` method contained a variable intended to filter out moves whose `operation_id` matched the `operation_id` of the entire recordset of work orders passed to the function. However, this filtering was performed inside a loop iterating over all work orders, even though the result of the filtration did not depend on any single work order. Before this commit: - The filtration was executed repeatedly for each work order, despite being deterministic. - This unnecessary repetition caused performance degradation and multiple redundant updates to the `picked` field of the same moves, resulting in fake or redundant database writes. After this commit: - The filtration logic has been moved outside the iteration, ensuring that the update to the moves is performed only once, improving overall performance and preventing redundant updates. - The `end_all` method is now executed on the entire recordset of work orders at once, instead of being called individually for each iteration. The benchmark below is done on a recordset of workorders of size **500** and the number of moves returned from the filter were **100**. It set the picked field to be **True** for every workorder in the recordset, potentially triggering recomputation of some of the fields and doing more redundant SQL queries. opw-5092636 ### Benchmark Results | Scenario | Execution Time | | :--- | :--- | | **Before this Commit** | **Memory Error** | **After this Commit** | **22 seconds** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The point of sale payment screen now shows a “force done” option even when a payment line is stuck waiting on a terminal response. This helps cashiers continue serving customers instead of getting blocked by an unresponsive payment device.
Original PR description
If a payment line is stuck in a waiting state (e.g. payment terminal not responding to a request), we now display the "force done" button, to avoid blocking the user. Forward-Port-Of: odoo/odoo#235244
Resolved issues and error corrections
This change fixes an error that could happen when Odoo checks which message was last seen by everyone in a conversation. It makes the check more reliable by using the member record directly, preventing crashes when some related user details are missing.
Original PR description
The `lastMessageSeenByAllId` compute function sometimes crashes when the persona linked to a member is unknown. This occurs because the compute function compares the member's persona to determine if it belongs to the current user. However, members are not always sent along with their persona. The compute function should instead compare the member directly to the current user's member. This fixes the issue and makes more sense. 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 fixes a test that could fail when running on Python 3.11 and later because record ordering was not being handled consistently. It helps keep the barcode batch module reliable across supported Python versions, preventing false test failures during development and deployment.
Original PR description
*: stock_barcode_picking_batch Steps to reproduce ================== Use python > 3.10 Run the test test_pack_batch_in_multiple_packages It fails on assertRecordValues, the records are not in the same order Cause of the issue ================== Recordsets ordering is not stable across python versions. It is implemented as `return set(self._ids) < set(other._ids)` https://github.com/odoo/odoo/blob/8a026b875a9b70f12689cdbd71d7e54b987d0612/odoo/models.py#L6636 Since this is a subset check, it always returns false when called with different ids Solution ======== Compare using the id directly opw-231140 Forward-Port-Of: odoo/enterprise#99118
The fleet tax report logic and its test were moved out of the Community build and into the Enterprise module where the needed vehicle data exists. This fixes a build failure in Community and keeps the fleet-specific reporting working where it is supported.
Original PR description
Community build was failing with: ``` FAIL: TestAccountFleet.test_tax_report_with_vehicle_split_repartition Traceback (most recent call last): File '/data/build/odoo/addons/account_fleet/tests/test_account_fleet.py', line 99, in test_tax_report_with_vehicle_split_repartition self.assertEqual(len(tax_details), 2) AssertionError: 0 != 2 ``` The test and SQL join logic relied on `vehicle_id` propagation that only exists in the enterprise addon `account_accountant_fleet`. Since the community edition cannot populate `vehicle_id` on tax lines, the query always returned zero rows, causing the failure. To fix this, the fleet-specific tax report query and test have been moved to the enterprise module, where the vehicle-aware tax reporting functionality actually resides. This keeps community builds green while retaining the intended behavior in enterprise. runbot error:233462
A fleet-specific tax reporting test and its supporting query were moved into the Enterprise version where the needed vehicle data is available. This prevents community builds from failing while preserving the intended fleet tax reporting behavior for Enterprise users.
Original PR description
Community build was failing with: ``` FAIL: TestAccountFleet.test_tax_report_with_vehicle_split_repartition Traceback (most recent call last): File '/data/build/odoo/addons/account_fleet/tests/test_account_fleet.py', line 99, in test_tax_report_with_vehicle_split_repartition self.assertEqual(len(tax_details), 2) AssertionError: 0 != 2 ``` The test and SQL join logic relied on `vehicle_id` propagation that only exists in the enterprise addon `account_accountant_fleet`. Since the community edition cannot populate `vehicle_id` on tax lines, the query always returned zero rows, causing the failure. To fix this, the fleet-specific tax report query and test have been moved to the enterprise module, where the vehicle-aware tax reporting functionality actually resides. This keeps community builds green while retaining the intended behavior in enterprise. runbot error:233462
This update prevents Serbian VAT numbers from being stored with the country prefix twice in generated XML files. It helps ensure partner tax information is exported in the correct format and avoids issues with downstream processing.
Original PR description
By setting for a Serbian partner a VAT with the prefix RS, they will have a duplication of the country code in the XML Ticket [link](https://www.odoo.com/odoo/project.task/5126028) opw-5126028
This update fixes several issues in Uruguay vendor bill synchronization and XML imports. It now processes all bills found in an uploaded XML, improves document identification for manually imported and automatically synced bills, and stores the XML attachment for easier tracking and troubleshooting.
Original PR description
1) Update l10n_uy_edi translations. 2) When an uruguayan xml file is uploaded on a purchase journal it could contain the information of more than one CFE but before this commit only the first CFE was…
1) Update l10n_uy_edi translations. 2) When an uruguayan xml file is uploaded on a purchase journal it could contain the information of more than one CFE but before this commit only the first CFE was processed. Now all the CFEs are processed. 3) Add suffix '-manual' for new vendor edi documents uuid that are created by drag and drop xml file. 4) Create xml attachment in the edi document if it is created by drag and drop xml file. 5) Add suffix '-notification' for new vendor edi documents uuid that are created by 'UY: Create vendor bills (sync from Uruware)'. 6) Cron is run by batches (size=10). 7) Add tests. The suffixes -manual and -notification are used to differentiate between EDI documents generated manually and those generated automatically. This is useful to determine whether the document was created by a user or by an automated process, also helps users identify its origin more easily and also it is useful for debugging and tracking purposes. Task Adhoc side: 43467 Task latam side: 1355
Signed documents now remain visible to both the person who requested the signature and the person who signed it. This fixes an issue where the requester could not find the completed document in Documents, improving access and document tracking.
Original PR description
To reproduce: ============= - as a User U with Admin rights on Documents (not Sys Admin) - create a folder at the root of the company - create a Sign Request template using this folder as signed document folder - send the Sign Request to another user O and sign it with that user O - go to Documents app with user U and check the folder where the signed document should be - the signed document is not there Problem: ======== when creating signed documents, the access rights for the requester are not set, causing the requester to not see the signed document Solution: ========= give `view` access right on signed documents to both the requester and the signer if they don't already have `edit` access right on it or ownership opw-[5087233](https://www.odoo.com/web#id=5087233&view_type=form&model=project.task)
This update makes the POS correctly show an error when the Belgian blackbox or IoT box is disconnected. It also informs staff when an order could not be sent to the preparation display, helping avoid hidden ordering issues and confusion during service.
Original PR description
Steps to reproduce: 1. Configure POS with Belgian blackbox and preparation display 2. Clock in as normal and start an order 3. At this point, disconnect the Blackbox or the IoT box 4. Try to order some more items Expected behaviour: - An error message is received, informing the user of the blackbox error AND telling them the order has not been sent to the preparation display. Actual behaviour: - In the case the IoT is connected but the blackbox is not - The POS is stuck with a loading spinner forever - A prepration order is printed but not sent to the prepration display - In the case the IoT box is disconnected - An IoT box network error dialog shows, but it does not mention the blackbox or preparation display - A prepration order is printed but not sent to the prepration display The cause of this is that we were previously ignoring the result of the blackbox action. The fix is just to save the result and handle it appropriately. task-5253038
This update corrects and simplifies the translated labels used for Italian electronic document types. It helps ensure users see clearer and more accurate names when creating or reviewing these documents.
Original PR description
Simplified and fixed labels and labels translations. Ref: https://help.fattureincloud.it/help/articolo/544-crea-autofattura-elettronica Ref: https://fex-app.com/FatturaElettronica/FatturaElettronicaBody/DatiGenerali/DatiGeneraliDocumento/TipoDocumento Forward-Port-Of: odoo/odoo#233943
The web app now preserves the current page when redirecting scoped app URLs, instead of sending users back to the home screen. This makes links like Discuss open directly to the intended page and avoids losing navigation state.
Original PR description
This commit fixes the '/scoped_app' redirection to '/odoo' without loosing the history state. Previously, when opening a route such as '/scoped_app/discuss', the webclient would use an empty state and redirect to the home screen with '/odoo' instead of redirecting to '/odoo/discuss'. Two tests have been added in router to assert the different redirection behavior when using scoped apps from the browser instead of a standalone app. task-5159471
This change fixes how rounding is applied in several accounting test scenarios, helping ensure totals and reconciliations behave as expected. It also updates outdated comments and test values so they better reflect real cases, reducing the risk of confusion and regressions.
Original PR description
Also fixes the comments that were wrong. Change some values to better test things 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 update fixes an intermittent issue where a Knowledge article could open in the wrong state after reorganizing articles in the sidebar. It makes the editor reliably show the article the user clicked, improving stability during normal editing and reordering workflows.
Original PR description
Before this commit, the `test_knowledge_main_flow` tour sometimes failed. That tour creates articles, then d&d one of them in the sidepanel to re-organize articles, and then clicks on a previously…
Before this commit, the `test_knowledge_main_flow` tour sometimes failed. That tour creates articles, then d&d one of them in the sidepanel to re-organize articles, and then clicks on a previously created article to continue editing it. The tour failed on that step, as the previously created clicked article wasn't properly selected/displayed in the editor. The race condition was that two (non synchronized) calls to the `load` function of the model were done: one after the move because the move could have altered the displayed article (1) and one because we selected another article to open by clicking in the sidebar (2). (1) is done without resId (reload the current article) and (2) is done with the id of the clicked article. Depending on the order these two calls are done, we end up with the clicked article displayed (if (2) is done after (1)), or with the current article still displayed, but reloaded ((1) done after (2)). This commit fixes the race condition by forcing the reload of the current record for (1), instead of blindly reloading the model, which might have changed/been requested something else meanwhile. runbot error~182073
This change ensures product cost on a sales order line can be updated again after an order has been confirmed, canceled, and reset to draft. It fixes a case where the cost could stop refreshing, which helps keep margin calculations accurate when the pricing currency changes.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Have a product with a purchase cost; 2. have sale margins enabled; 3. add a the product to a quotation; 4. change pricelist to one with a different currency; 5. note that the line's cost gets updated; 6. change order state to confirmed, then canceled, then back to draft; 7. change pricelist again. Issue ----- The purchase cost no longer update. Cause ----- The `_compute_purchase_price` override in `sale_stock_margin` doesn't pass the line to `super` if it `has_valued_move_ids`. This hook only checks for the existence of linked `move_ids` on the record with no regard for their state. Solution -------- 1. Move the `has_valued_move_ids` hook from `sale` to `sale_stock`. 2. Only return `True` if any of the moves aren't in draft or canceled. opw-5147321 Forward-Port-Of: odoo/odoo#233746
Opening Studio from a calendar view now works even when one of the calendar fields is restricted by group settings. This fixes a crash that previously blocked users from editing those calendar views in Studio.
Original PR description
Have a calendar view that has a field A. the field A has a group on it, defined either in python or in the XML. Before this commit, opening studio in the calendar view crashed, because calendar did not support yet those fields that are marked with studio_no_fetch in their attributes. After this commit, there is no crash Forward-Port-Of: odoo/enterprise#98903
This change corrects a typo in the signup flow code so it uses the right progress-tracking method available in the targeted Odoo version. It helps keep the signup process aligned with the current platform and avoids compatibility issues.
Original PR description
``_commit_progress`` is available since saas-18.2 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 fix restores the ability to use previously saved payment methods when paying an invoice. It matters because customers who saved their card or payment token during an earlier payment can now select it again instead of having to re-enter payment details.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Create a sales order for a company partner; 2. create & copy a payment link; 3. open payment link in new session; 4. using demo provider, make the payment & save payment details; 5. add an invoice address to the company partner; 6. create an invoice for the company partner using the invoice address; 7. confirm invoice; 8. click "Register Payment"; 9. select "Demo" as payment provider. Issue ----- The saved payment token cannot be selected. Cause ----- Before commit 75f4008, the company partner was used to search for tokens in the payment register wizard. After the commit, the the invoice partner is used, making it impossible to select previously accessible payment tokens. Solution -------- Search payment tokens linked to either partner. opw-5193718 Forward-Port-Of: odoo/odoo#234173
Miscellaneous changes
This pull request appears to be a test submission for technical onboarding rather than a business feature change. It does not describe a user-facing change, so it should have no practical impact for business users.
Original PR description
Test for technical onboarding 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
3 changes
Enhancements to existing features
When a payment line gets stuck waiting for a payment terminal response, the POS now shows a “Force Done” option. This helps staff move forward instead of being blocked by an unresponsive terminal.
Original PR description
If a payment line is stuck in a waiting state (e.g. payment terminal not responding to a request), we now display the "force done" button, to avoid blocking the user.
When a user creates a new company bank account, Odoo now keeps the expected account number length and increments it correctly. This avoids generating bank account numbers with an extra digit, which helps prevent confusion and formatting issues.
Original PR description
**Description of the issue/feature this PR addresses:** When user creates a new company bank account the new account created has not expected lenght when last digits are more than 1 **Current behavior before PR:** account digits = 6 last bank account = **572009** create new bank account = **5720010** **Desired behavior after PR is merged:** account digits = 6 last bank account = **572009** create new bank account = **572010** cc @Tecnativa --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This fix restores the ability to choose previously saved payment details when registering a payment for a customer invoice. It matters because businesses can again reuse stored payment methods for the right customer, avoiding failed payment setup and extra manual work.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Create a sales order for a company partner; 2. create & copy a payment link; 3. open payment link in new session; 4. using demo provider, make the payment & save payment details; 5. add an invoice address to the company partner; 6. create an invoice for the company partner using the invoice address; 7. confirm invoice; 8. click "Register Payment"; 9. select "Demo" as payment provider. Issue ----- The saved payment token cannot be selected. Cause ----- Before commit 75f4008, the company partner was used to search for tokens in the payment register wizard. After the commit, the the invoice partner is used, making it impossible to select previously accessible payment tokens. Solution -------- Search payment tokens linked to either partner. opw-5193718