Wednesday, November 12, 2025
20 changes · 18.0
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 update refreshes the official Luxembourg payroll rule numbers for 2025. It helps ensure payroll calculations stay aligned with the latest legal requirements and reduces the risk of incorrect withholding amounts.
Original PR description
Update the official numbers of the Luxembourg payroll rules for 2025. This is a backport of PR https://github.com/odoo/enterprise/pull/79805 task-5187202 Forward-Port-Of: odoo/enterprise#98763
Resolved issues and error corrections
This change corrects how spreadsheet inputs are displayed when they are missing or invalid, so the warning state is always visible. It also prevents dark mode styling from breaking the spreadsheet’s default layout, improving consistency for users.
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
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
This change prevents event tickets from being switched into a rental-style setup that the website event registration flow cannot handle. It avoids a payment-time error and keeps event ticket setup consistent so customers can register without issues.
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
This update fixes issues in spreadsheet data sources and filters so broken connections now return the correct error instead of failing silently. It also removes a confusing clear button when a filter is invalid, making the interface clearer and more consistent.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change prevents spreadsheet filter screens from crashing when a datasource or filter is broken after a migration or model change. It also makes cleanup easier by showing delete options more consistently, helping users repair spreadsheets and keep working without errors.
This fix prevents a table embedded inside another table from expanding beyond the boundaries of its parent cell when resized. As a result, the content remains editable and users can continue working without layout issues.
Original PR description
**Current behavior before PR:** - When a table was created inside another table, resizing the inner table could cause it to overflow its parent cell, making it uneditable. **Desired behavior after PR is merged:** - The inner table no longer overflows its parent cell when resized, ensuring it remains editable. task-5216916 Forward-Port-Of: odoo/odoo#233554
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
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 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 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