Daily updates from Odoo
Navigate
Branch
Saturday, May 23, 2026
43 changes
5 changes
Enhancements to existing features
This update enhances the Indian Profit & Loss report by incorporating 'Other Expenses' into the calculations. This ensures the report accurately reflects all overhead costs, aligning with standard accounting practices and providing a more complete financial picture for Indian businesses using Odoo Enterprise.
Original PR description
Update the Indian P&L report structure to capture accounts categorised under 'Other Expenses'. This ensures that the net profit calculation accounts for all overheads, aligning with standard accounting practices. task-6166626 Forward-Port-Of: odoo/enterprise#115402
Resolved issues and error corrections
This update fixes an issue where fiscal positions weren't correctly created for US companies due to an outdated configuration. Now, fiscal positions are automatically generated based on the correct localization (US or Canada), ensuring accurate accounting and tax reporting. This simplifies the system and improves data accuracy.
Original PR description
The fiscal position was being created specifically for countries using the Generic CoA. This stems from before the US had its own CoA [1]. Because of this, US companies no longer had an Avatax fiscal position created for them. Now that the US has its own CoA, we move to a simpler `@template()` approach and take the opportunity to add Canada as well. [1] odoo/odoo#223745 task-6228639 Forward-Port-Of: odoo/enterprise#117966
This update fixes an issue where embedded actions didn't always display the correct translated names, especially after language changes or server action updates. By delegating the display name, the system now ensures embedded action names are always up-to-date and accurately translated, improving the user experience.
Original PR description
When an embedded action is created from a server action, its name is just stored as is. When using these actions e.g. in the Documents top bar, there is already a "hack" to copy the name of the…
When an embedded action is created from a server action, its name is just stored as is. When using these actions e.g. in the Documents top bar, there is already a "hack" to copy the name of the server action to the embedded action in each active language. This has a few issues: - When a language is activated after the embedded action creation, the name of the server action is not copied to the embedded action, resulting in an untranslated name. - When the name of the server action is changed, the name of the embedded action is not updated, resulting in an outdated and possibly untranslated name. The workaround is to disable/enable the action now, but it's not very user-friendly and can be easily forgotten. To fix this, we can simply delegate the display name of the embedded action to the linked server action. This way, the name of the embedded action will always be up to date and correctly translated. Related: https://github.com/odoo/enterprise/pull/116369 Forward-Port-Of: odoo/odoo#265342 Forward-Port-Of: odoo/odoo#262981
This update removes a redundant step in creating embedded actions within Odoo. Previously, a separate translation was required, but now the system automatically uses the translation from the linked action. This simplifies the process and ensures consistent translations across the system.
Original PR description
Now that `ir.embedded.actions` delegates its display name to the linked action, the manual translation copy on embedded action creation is no longer needed. Related: https://github.com/odoo/odoo/pull/262981 Forward-Port-Of: odoo/enterprise#117772 Forward-Port-Of: odoo/enterprise#116369
This update fixes a bug in the restaurant POS module that prevented capturing payments when customers entered a 0% tip. Stripe requires a capture for all payments, and this change ensures that a capture is always initiated, regardless of the tip amount, preventing pending transactions from being automatically cancelled.
Original PR description
Currently, the `pos_restaurant` module only calls capture payment within `validateTip` if there is an amount to tip. Since Stripe requires a capture for all payments and we defer that to later if it can be adjusted, this means that if customers have tip after payment enabled and enter a tip of 0%, it will never be captured, stay pending, and then be automatically cancelled later down the line. This commit catches that by hooking into the `validateTip` method and calling capture anyway on 0% tips. opw-6082596 Forward-Port-Of: odoo/odoo#265507 Forward-Port-Of: odoo/odoo#261129
7 changes
Enhancements to existing features
This update improves the accuracy of Indian Profit & Loss reports by incorporating 'Other Expenses' into the calculation. This ensures that net profit figures more closely align with standard accounting practices and provides a more complete financial picture for Indian businesses using Odoo Enterprise.
Original PR description
Update the Indian P&L report structure to capture accounts categorised under 'Other Expenses'. This ensures that the net profit calculation accounts for all overheads, aligning with standard accounting practices. task-6166626 Forward-Port-Of: odoo/enterprise#115402
Resolved issues and error corrections
This update fixes an issue where fiscal positions weren't correctly created for US companies due to an outdated configuration. Now, fiscal positions are automatically generated based on the correct localization (US or Canada), ensuring accurate accounting and tax reporting. This simplifies the system and avoids missing fiscal positions.
Original PR description
The fiscal position was being created specifically for countries using the Generic CoA. This stems from before the US had its own CoA [1]. Because of this, US companies no longer had an Avatax fiscal position created for them. Now that the US has its own CoA, we move to a simpler `@template()` approach and take the opportunity to add Canada as well. [1] odoo/odoo#223745 task-6228639 Forward-Port-Of: odoo/enterprise#117966
This update fixes an issue where embedded actions didn't always display the correct, translated names. By linking embedded action names to their server action counterparts, the system now automatically updates translations, ensuring consistent and accurate display across all languages. This improves the user experience and avoids confusion.
Original PR description
When an embedded action is created from a server action, its name is just stored as is. When using these actions e.g. in the Documents top bar, there is already a "hack" to copy the name of the…
When an embedded action is created from a server action, its name is just stored as is. When using these actions e.g. in the Documents top bar, there is already a "hack" to copy the name of the server action to the embedded action in each active language. This has a few issues: - When a language is activated after the embedded action creation, the name of the server action is not copied to the embedded action, resulting in an untranslated name. - When the name of the server action is changed, the name of the embedded action is not updated, resulting in an outdated and possibly untranslated name. The workaround is to disable/enable the action now, but it's not very user-friendly and can be easily forgotten. To fix this, we can simply delegate the display name of the embedded action to the linked server action. This way, the name of the embedded action will always be up to date and correctly translated. Related: https://github.com/odoo/enterprise/pull/116369 Forward-Port-Of: odoo/odoo#265342 Forward-Port-Of: odoo/odoo#262981
This update removes a redundant step in creating embedded actions within Odoo. Previously, a separate translation was required, but now that embedded actions use the linked action's display name, this manual translation is no longer necessary. This simplifies the process and ensures consistent translations.
Original PR description
Now that `ir.embedded.actions` delegates its display name to the linked action, the manual translation copy on embedded action creation is no longer needed. Related: https://github.com/odoo/odoo/pull/262981 Forward-Port-Of: odoo/enterprise#117772 Forward-Port-Of: odoo/enterprise#116369
This update fixes an issue where tip payments, even with a 0% tip, weren't always being fully processed by Stripe. The change ensures that a capture payment is always initiated, regardless of the tip amount, preventing pending payments from being automatically cancelled. This improves payment reliability for restaurant customers.
Original PR description
Currently, the `pos_restaurant` module only calls capture payment within `validateTip` if there is an amount to tip. Since Stripe requires a capture for all payments and we defer that to later if it can be adjusted, this means that if customers have tip after payment enabled and enter a tip of 0%, it will never be captured, stay pending, and then be automatically cancelled later down the line. This commit catches that by hooking into the `validateTip` method and calling capture anyway on 0% tips. opw-6082596 Forward-Port-Of: odoo/odoo#265507 Forward-Port-Of: odoo/odoo#261129
A recent update to Odoo's document processing caused errors when downloading signed documents through the Sign app. This fix ensures that compression is applied correctly after a document is merged, resolving compatibility issues with newer versions of the pypdf library. This prevents download failures and improves the reliability of the Sign app.
Original PR description
This [related PR] introduced a compression pass after calls to mergePage(). However in newer versions of pypdf (>=3.5.2), compress_content_streams() can only be called on pages of PdfWriter. An error would be raised when called on pages of a PdfReader. Steps to reproduce ----- 1. Run Odoo with pypdf>=3.5.2 2. Sign and download a document in the Sign app 3. Traceback occurs Fix ---- This commit moves the compression to the writer object, after the merged page has been added. Related pr: https://github.com/odoo/odoo/pull/261879 runbot-937761 Forward-Port-Of: odoo/odoo#266192 Forward-Port-Of: odoo/odoo#265304
This update resolves an issue where downloading signed documents through the Sign app was failing due to a compatibility problem with the pypdf library. The fix moves the document compression step to a later stage, ensuring it works correctly with the latest version of pypdf. This prevents errors and ensures smooth document downloads.
Original PR description
This [related PR] introduced a compression pass after calls to mergePage(). However in newer versions of pypdf (>=3.5.2), compress_content_streams() can only be called on pages of PdfWriter. An error would be raised when called on pages of a PdfReader. Steps to reproduce ----- 1. Run Odoo with pypdf>=3.5.2 2. Sign and download a document in the Sign app 3. Traceback occurs Fix ---- This commit moves the compression to the writer object, after the merged page has been added. Related pr: https://github.com/odoo/odoo/pull/261879 runbot-937761 Forward-Port-Of: odoo/enterprise#118257 Forward-Port-Of: odoo/enterprise#117756
9 changes
Enhancements to existing features
This update improves the accuracy of Indian Profit & Loss reports by incorporating 'Other Expenses' into the calculation. This ensures the reports align with standard accounting practices and provide a more complete picture of business profitability.
Original PR description
Update the Indian P&L report structure to capture accounts categorised under 'Other Expenses'. This ensures that the net profit calculation accounts for all overheads, aligning with standard accounting practices. task-6166626 Forward-Port-Of: odoo/enterprise#115402
Resolved issues and error corrections
This update fixes an issue where fiscal positions weren't correctly created for US companies due to an outdated configuration. Now, fiscal positions are automatically generated based on a company's localization (US or Canada), ensuring accurate accounting and reporting. This simplifies the system and improves data accuracy.
Original PR description
The fiscal position was being created specifically for countries using the Generic CoA. This stems from before the US had its own CoA [1]. Because of this, US companies no longer had an Avatax fiscal position created for them. Now that the US has its own CoA, we move to a simpler `@template()` approach and take the opportunity to add Canada as well. [1] odoo/odoo#223745 task-6228639 Forward-Port-Of: odoo/enterprise#117966
This update enhances the Timesheet Assistant by opening internal links within a modal window. This keeps users within the Timesheets Assistant menu, providing a smoother and more intuitive experience when navigating related tasks and information.
Original PR description
This commit opens the internal links in the custom form view displayed in the timesheet assistant inside a modal to stay in Timesheets Assistant menu. task-[6132392](https://www.odoo.com/odoo/project/4105/tasks/6132392)
This update corrects a formatting error in invoices generated with large prices. Previously, invoices displayed extra decimal places due to a calculation issue. The fix reduces the precision used in calculations to ensure invoices display only the necessary digits, improving data accuracy and presentation.
Original PR description
Issue: - Create an invoice with a line having a price of `528,000,000.00` - Print the invoice -> pdf displays `528,000,000.000001` Cause: In `value_to_html` from `ir.qweb.field.float`, we compute the maximum precision that we can get from the value, to avoid parasite digits. The maximum is 15, so if a number has 11 digits, we won't ask for a precision higher than 4. But in `float_round`, they multiple the value with its precision, then add `epsilon` (a small value). So we're now working with a 16 digits float, which is what we want to avoid. Solution: Reduce the maximum precision from one digit before calling `float_round`. opw-6012129 Forward-Port-Of: odoo/odoo#265696 Forward-Port-Of: odoo/odoo#260955
This change refactors the partner retrieval logic within the account statement line processing to avoid redundant queries. By intelligently filtering partners based on initial matching criteria (bank account), the system eliminates unnecessary searches based on name, preventing performance degradation and improving query efficiency. This optimization primarily targets scenarios where multiple statement lines might initially match on the bank account, reducing the overall processing time.
Original PR description
Various improvements related to performance for `<account.bank.statement.line>._retrieve_partner` Forward-Port-Of: odoo/enterprise#117738
This update fixes an issue where embedded actions didn't always display the correct translated names, especially after language changes or server action updates. The fix delegates the action's display name to the linked server action, ensuring consistent and accurate translations across all languages. This improves the user experience and avoids confusing untranslated names.
Original PR description
When an embedded action is created from a server action, its name is just stored as is. When using these actions e.g. in the Documents top bar, there is already a "hack" to copy the name of the…
When an embedded action is created from a server action, its name is just stored as is. When using these actions e.g. in the Documents top bar, there is already a "hack" to copy the name of the server action to the embedded action in each active language. This has a few issues: - When a language is activated after the embedded action creation, the name of the server action is not copied to the embedded action, resulting in an untranslated name. - When the name of the server action is changed, the name of the embedded action is not updated, resulting in an outdated and possibly untranslated name. The workaround is to disable/enable the action now, but it's not very user-friendly and can be easily forgotten. To fix this, we can simply delegate the display name of the embedded action to the linked server action. This way, the name of the embedded action will always be up to date and correctly translated. Related: https://github.com/odoo/enterprise/pull/116369 Forward-Port-Of: odoo/odoo#265342 Forward-Port-Of: odoo/odoo#262981
This update removes a redundant step in creating embedded actions within Odoo. Previously, a separate translation was required, but now that embedded actions inherit their display names directly, this manual process is no longer necessary. This simplifies the action creation workflow and ensures consistent translations.
Original PR description
Now that `ir.embedded.actions` delegates its display name to the linked action, the manual translation copy on embedded action creation is no longer needed. Related: https://github.com/odoo/odoo/pull/262981 Forward-Port-Of: odoo/enterprise#117772 Forward-Port-Of: odoo/enterprise#116369
This update fixes an issue where tip payments, even with a 0% tip, weren't always being fully processed by Stripe. The change ensures that a capture payment is always initiated, regardless of the tip amount, aligning with Stripe's requirements and preventing pending payments from being automatically cancelled. This improves payment accuracy and reliability for restaurant orders.
Original PR description
Currently, the `pos_restaurant` module only calls capture payment within `validateTip` if there is an amount to tip. Since Stripe requires a capture for all payments and we defer that to later if it can be adjusted, this means that if customers have tip after payment enabled and enter a tip of 0%, it will never be captured, stay pending, and then be automatically cancelled later down the line. This commit catches that by hooking into the `validateTip` method and calling capture anyway on 0% tips. opw-6082596 Forward-Port-Of: odoo/odoo#265507 Forward-Port-Of: odoo/odoo#261129
This update fixes issues with website translations, ensuring accurate formatting and preserving text meaning. It now correctly handles metadata like image attributes and prevents multiple translation requests, leading to a more reliable and consistent user experience for translated content. This improves the quality of our global website offerings.
Original PR description
This commit fixes and improves several aspects of the recently merged
[translate the whole page].
- Fix formatting issues in the translation like:
- Space getting removed while translating
- Meaning of text is not preserved after translation.
- Example :
- 'Enhance Your' and '<b>Experience</b>' becomes, 'Enhance Your<b>Enhance Your Experience</b>'
- 'hello <b>world</b>' becomes 'Hola<b>mundo</b>' space is trimmed.
- Exclude non-translatable elements such as `.o_brand_promotion` from
translation.
- Support metadata translation, ensuring that translatable attributes
are correctly handled (`alt`, `title`, `placeholder`, and `value`
attributes).
- Disable the “Translate” button while the translation process is
running to prevent multiple concurrent requests.
[translate the whole page]: https://github.com/odoo/odoo/commit/6e1e359ec6a7ae23cfa7d7c96380f845c7fdcfe5
task-5047714
Forward-Port-Of: odoo/odoo#2298942 changes
Resolved issues and error corrections
This update fixes an issue where tip payments, even with a 0% tip, weren't always being fully captured by Stripe. The change ensures that a capture payment is always initiated, aligning with Stripe's requirements and preventing pending payments from being automatically cancelled. This improves payment accuracy and reliability for restaurant orders.
Original PR description
Currently, the `pos_restaurant` module only calls capture payment within `validateTip` if there is an amount to tip. Since Stripe requires a capture for all payments and we defer that to later if it can be adjusted, this means that if customers have tip after payment enabled and enter a tip of 0%, it will never be captured, stay pending, and then be automatically cancelled later down the line. This commit catches that by hooking into the `validateTip` method and calling capture anyway on 0% tips. opw-6082596 Forward-Port-Of: odoo/odoo#265507 Forward-Port-Of: odoo/odoo#261129
This update corrects a technical issue that was preventing accurate bank statement matching for multi-step transfer processes (like payouts to internal accounts and then to destination banks). The fix now correctly handles these complex flows, ensuring that matching is accurate and reliable. It focuses on receivable and payable accounts to maintain the original intended functionality.
Original PR description
Commit e2a9f3bfbb8a excludes from the bank statement matching domain any AML whose source statement line is already reconciled, to prevent false-positive label matches on past manual counterparts. However, the filter is applied to every account type, which breaks legitimate multi-step reconciliation flows on liquidity / transfer accounts (e.g. payout -> internal transfer account -> destination bank). After the first statement line is reconciled, the transfer-account AML is no longer offered as a candidate for the destination bank line; the line falls back to the suspense account and the AML is also invisible in "Match Existing Entries". Scope the new filter to receivable / payable accounts only, which is the case the original commit was actually guarding against. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266140 Forward-Port-Of: odoo/odoo#265653
17 changes
New functionality added to Odoo
This update adds a new field for NISS (National Identification Number) directly to the employee search view within the Odoo Enterprise system. This allows for more precise employee identification and reporting, aligning with Belgian payroll requirements. It improves the accuracy of employee data retrieval for HR and accounting processes.
Original PR description
Adds the NISS field directly to the employee search view task:6233643
Enhancements to existing features
This update simplifies Odoo controller code by replacing `request.env` with `self.env`, aligning with existing model practices. This change reduces code complexity and improves maintainability, ensuring a more consistent and efficient system.
Original PR description
*= `payment_sepa_direct_debit, sale_(amazon, lazada, shopee), website_sale_(*)` Purpose of this commit: - Since https://github.com/odoo/odoo/commit/9ce68df56cf01ad166de4d21d1670fbd9631940d, `self.env` can also be used in controllers as a replacement for `request.env`. This significantly reduces the need to import and rely on request in controller code. - Using request has already become bad practice in models. With this change, we aim to reduce its usage in controllers as well, aligning controller code more closely with model practices. - Therefore, within our scope, all occurrences of `request.env` are replaced with `self.env` wherver possible. See also: - https://github.com/odoo/odoo/pull/262467 task-6172360
This update enhances the Odoo Enterprise phone system by adding tooltips to long names displayed in call summaries and contact information. This improves usability by providing more context and detail for users, particularly when dealing with lengthy names or numbers.
Original PR description
Task-6179948
Resolved issues and error corrections
This update fixes an issue where ticket close times were inaccurate when tickets were reopened and closed again. Now, the calculation considers only the time spent in currently open stages related to the ticket's team, providing a more precise record of time spent resolving the issue. This ensures more reliable reporting on support team efficiency.
Original PR description
Issue: When a ticket is reopened and closed again, `close_hours` included time spent in previous closing stages, causing inaccurate total close time. Before this commit: The `close_hours` field was computed as the total time from ticket creation to close date. If a ticket was closed and later reopened, the time spent in the closed stage was still included in the final `close_hours`, which led to inaccurate results. After this commit: `close_hours` is now computed by summing the working minutes from `duration_stage_tracking` field, considering only the open stages related to the ticket's team. task-4133988
This update allows Invoicing Administrators to delete or edit reconciled lines in the accounting system, resolving a previous restriction. The change ensures consistent access control based on the line's review status, aligning with existing accounting rules and improving usability for administrators. This update was driven by a bug fix related to privilege checks.
Original PR description
Deleting or editing a reconciled line raised "Validated entries can only be changed by your accountant." for Invoicing Administrators because the check only tested `group_account_user`, which is not granted by the Invoicing privilege chain. Delegate to `AccountMove._check_review_state_access()` to apply the same rules as `account.move`: - `'supervised'` → requires `group_account_manager` - `'reviewed'` → requires `group_account_user` or `group_account_manager` - `'todo'` / `'anomaly'` → no restriction opw-6128792 Forward-Port-Of: odoo/enterprise#117795 Forward-Port-Of: odoo/enterprise#114833
This update fixes an error in how VAT reimbursement moves are generated when unclaimed tax is carried over to the next month. The previous calculation incorrectly used data from the previous month's tax report, leading to inaccurate reimbursement amounts. This ensures accurate VAT reporting and proper reimbursement processing.
Original PR description
When generating a VAT return with an unclaimed tax amount carried to the next month, the carryover reimbursement move amounts are computed with an incorrect ratio. Steps to reproduce: - Create and…
When generating a VAT return with an unclaimed tax amount carried to the next month, the carryover reimbursement move amounts are computed with an incorrect ratio. Steps to reproduce: - Create and post a bill in May containing a VAT amount. - Create and post a bill in June containing a VAT amount. - Create a VAT return for May to carry over the VAT amount to the next month. - Create a VAT return for June, requesting the full VAT amount to be reimbursed. - Validate and send the June VAT return. - Check the generated reimbursement move Issue: Line values does not correspond to anything real/tangible. It occurs because when computing the ratio for the move we check the last tax report entry, where we find the amount of tax from the past months and a line balancing the last month that should not be taken into account. The "Balance tax current account (receivable)" line from the tax closing entry is mistakenly picked up as a tax carried forward line, throwing off the amounts. opw-5961836 Forward-Port-Of: odoo/enterprise#117927 Forward-Port-Of: odoo/enterprise#115451
This update fixes a bug where the Odoo Agent would repeatedly fail when updating records without the specific 'natural language query' topic. By adding a list of available menus and models to the context, the Agent now correctly identifies and interacts with records, preventing timeouts and improving stability.
Original PR description
Purpose: -------- The update and create tools can generate a link to show a preview of the created/updated record. However, the list of available menus is only added when the agent has the natural language query topic. Therefore, when using the Odoo Agent (that does not have that topic) to update a record, the LLM loops on the update record tool guessing random menu ids and eventually times out because the tool calls fail since the menu ids guesses do not match the model of the updated record. The list of available menus is now added in the context if the create or update records topics are available on the agent. The list of available models has also been added in this case. Task-6236642 Forward-Port-Of: odoo/enterprise#117998
This update fixes a problem where adding rental products to the cart would fail due to mismatched date calculations. The fix ensures that rental product durations are correctly handled, preventing errors when mixing different rental periods and improving the overall rental experience. This resolves a conflict between how dates are stored and processed during the cart addition process.
Original PR description
Steps to reproduce: =================== 1. Go to the shop page and use the rental date picker to select a start and end date with hours. 2. Find a rental product configured with "Days" pricing. 3.…
Steps to reproduce: =================== 1. Go to the shop page and use the rental date picker to select a start and end date with hours. 2. Find a rental product configured with "Days" pricing. 3. Add to card directly from the product card 4. Add a rental product from product image that has date type value date 5. Go to that product details page. 6. Click add to cart -> Invalid operation, You cannot mix different rental periods... Cause: ====== When adding a product from the shop list view, the system uses the default start/end dates (from the rental period) exactly as first added. However, the "Add to Cart" logic on the product details page attempts to adapt the selected dates to the product's specific rental unit (e.g., normalizing the time component for 'Day' pricing). This re-calculation creates a timestamp mismatch between the item already in the cart (from the shop view) and the new item being added (from the details page). Solution: ========= The add-to-cart flow has been updated to correctly utilize the default duration values (the globally selected dates) if they exist. opw-5450576 Forward-Port-Of: odoo/enterprise#117946 Forward-Port-Of: odoo/enterprise#103373
This update resolves an issue where users would encounter an error when attempting to sign in to planning slots without a defined end date. The fix ensures that the system handles empty end dates gracefully, preventing the error and allowing users to successfully schedule tasks. This improves the overall reliability of the planning feature.
Original PR description
Currently, an error occurs when user tries to signin on a planning slot which doesnt have an end date selected.
Steps to replicate:
- Install `planning_field_service` and open Planning.
- Click New > Add a Customer > Change status to `Scheduled`.
- Remove end datetime (right one) > Click `Sign In`.
Error:
```
File '/home/odoo/odoo19/enterprise/planning_field_service/models/planning_slot.py', line 264, in action_sign_in
if now > self.end_datetime.astimezone(ZoneInfo('UTC')):
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'bool' object has no attribute 'astimezone'
```
Cause:
- As the user removed value from end datetime, `self.end_datetime` is False so we get this error when trying to access `self.end_datetime.astimezone()`.
Solution:
- Added a conditonal check for `self.end_datetime` before accessing `self.end_datetime.astimezone()`.
sentry-7480608465
Forward-Port-Of: odoo/enterprise#117425This update fixes an issue where users could attempt to change assets to draft after setting lock dates in the accounting system. This prevented users from modifying finalized accounting records, ensuring data integrity and compliance with accounting standards. The change restricts draft status for assets after lock dates are applied.
Original PR description
Steps to reproduce: 1- Install Accounting 2- Go to [Accounting -> Assets] and create a new asset with start date 1/1/2025 3- Specify the fixed asset account and confirm the asset 4- Open [Accounting…
Steps to reproduce: 1- Install Accounting 2- Go to [Accounting -> Assets] and create a new asset with start date 1/1/2025 3- Specify the fixed asset account and confirm the asset 4- Open [Accounting -> Lock Dates] 5- Set a Lock date on everything with the date 31/12/2025 and save 6- Cancel the asset, set to draft and confirm again Issue: `Invalid Operation: The remaining value on the last depreciation line must be 0` Expected behavior: Should not be able to set to draft once the asset is cancelled Why this happens: Commit 66db1d5 introduced a new condition on the `Set to Draft` button which results in the button being visible when it should not be. If a Lock Date is set after an asset is confirmed, the acquisition and any depreciation entries are effectively finalized in the accounting history. Allowing a user to "Set to Draft" at that point would involve deleting or modifying entries in a closed period, which violates accounting integrity. opw-6152777 Forward-Port-Of: odoo/enterprise#116900
This update enhances the working files reporting feature by adding a confirmation step when deleting files, preventing accidental data loss. It also ensures all working files open in the standard cycle view and displays embedded actions correctly. These changes improve the user experience and data integrity for account reports.
Original PR description
contains: [FIX] account_reports: Working files delete button: - hide it for non-accountant - add confirmation dialog [FIX] account_reports: Working file should always open in cycle view [FIX] account_reports: Always show embedded actions in Working files task-5880319 Forward-Port-Of: odoo/enterprise#117831 Forward-Port-Of: odoo/enterprise#115596
This update resolves an issue preventing normal users from canceling approval requests they created. The fix utilizes 'sudo' to grant the correct permissions, allowing users to successfully cancel their own approvals and streamlining the workflow.
Original PR description
Issue: - A user who created an approval request could cancel it. But a rights error appeared during the cancellation. Steps to Reproduce: - Create an approval being a normal user. - Try to cancel the approval. - A ValidationError is raised eventhough the approvals can be cancelled by creator of it. Fix: - Changed the cancel action to use the sudo for the user who created the task and can cancel it Impact: - Users can cancel their own approval requests without errors. Task: 6123104 Forward-Port-Of: odoo/enterprise#114189
This update resolves a crash that occurred when users clicked the 'hide' button on the payroll dashboard due to an error in how in-memory payrun warnings were handled. The fix ensures warnings are correctly identified and processed, preventing the database error and improving dashboard stability. This change impacts the payroll dashboard functionality.
Original PR description
Closing date payrun warnings are created as in-memory records (.new()), giving them a NewId instead of a real integer DB id. When the user clicked the hide button, this NewId string was passed to action_snooze/action_archive, causing a psycopg2.errors.InvalidTextRepresentation SQL error. Fix by sending False as the id for in-memory warnings in get_payroll_dashboard_warning_cards, and suppressing the hide button on the dashboard when warning.id is falsy. task-6205849 Forward-Port-Of: odoo/enterprise#117854
This update resolves an issue where the generic tax report wouldn't display an error message when dealing with negative net values. The fix ensures that the report accurately checks for tax discrepancies, regardless of whether the net amount is positive or negative, improving report reliability.
Original PR description
**Issue:** In the generic tax report, a check is performed on the report lines to ensure that the declared tax amount is consistent with the expected amount. If the difference between the declared tax amount and the expected one is higher than 0.1% of the declared net amount, then a error message is displayed. If the net amount is negative, the error message is never displayed because the computed percentage of the tax difference is negative and therefore lower than 0.1% (i.e. 0.001). opw-6014350 Forward-Port-Of: odoo/enterprise#117990
This update fixes an issue where the POS incorrectly applied AvaTax fiscal positions even when AvaTax wasn't activated in the POS settings. The system now prioritizes AvaTax fiscal positions only when AvaTax is enabled in the accounting settings, ensuring accurate tax calculations for POS transactions. This improves the reliability of the Point of Sale tax functionality.
Original PR description
**Steps to reproduce:** - Install Accounting and Point of Sale - In Accounting settings, activate "AvaTax" - Configure the AvaTax fiscal position and activate "Detect Automatically" option - Make…
**Steps to reproduce:** - Install Accounting and Point of Sale - In Accounting settings, activate "AvaTax" - Configure the AvaTax fiscal position and activate "Detect Automatically" option - Make sure that the other fiscal positions don't have that option set or that they are ordered after the AvaTax one - Go to the settings of a point of Sale - Activate "Flexible Taxes" and configure "Default" and "Allowed" - Make sure that AvaTax fiscal position is not allowed - Do not activate "AvaTax PoS Integration" - Open a POS session - Select a customer with an address in the US and without fiscal position - Check the fiscal position **Issue:** The selected fiscal position is the AvaTax one even though AvaTax is not activated in the POS. **Cause:** We force the use of a fiscal position if it is configured on a customer. In this case, as no fiscal position is configured on the customer, we try to retrieve one that matches the condition and the AvaTax one is selected. **Solution:** When searching for the fiscal position of a customer, if AvaTax is not configured in the POS and if its fiscal positions are not allowed in POS, we ignore the fiscal positions using AvaTax. opw-6154089 Forward-Port-Of: odoo/enterprise#116626
This update fixes a potential error message displayed when spreadsheets are unavailable, preventing disruptions to user workflows. The change handles server errors within the system, eliminating the need for complex template modifications and streamlining the process. This improves stability and user experience.
Original PR description
The fix suggested in #81276 did not account for other spreadsheet models than a document as it required some modification in the component template. The same logic should then have been forwarded to other models (quality.check for instance] but that process is error prone. This revision changes the approach by handling the server error inside the abstract action so that no template modification is required. task-6208222 Forward-Port-Of: odoo/enterprise#117934 Forward-Port-Of: odoo/enterprise#117221
This update fixes inconsistencies in how barcode settings are applied to Manufacturing Orders. Previously, mandatory scan requirements weren't consistently enforced, allowing users to bypass them. Now, the system correctly utilizes MRP operation type configurations, ensuring accurate barcode tracking during production processes.
Original PR description
Before this commit, the "Allow full order validation" were partially ignored in the Barcode app when used for Manufacturing Orders, and the "Mandatory scan" settings didn't work very well. For…
Before this commit, the "Allow full order validation" were partially ignored in the Barcode app when used for Manufacturing Orders, and the "Mandatory scan" settings didn't work very well. For example, setting the scan of lot/serial as mandatory didn't prevent the user to set automatically a SN on consummed component by generating a lot/serial on the produced product or by clicking on "Produce All" button. This commit adds some conditions to avoid to update barcode lines in case they should depending of the config. This commit also fixes a related issue where the MRP operation type's config wasn't used at all when a MO is created directly from the Barcode app. As the config is get from the MO's picking type and no MO exists when a new one is created from the Barcode app, there is no MO's config returned in the data send by the server. To fix that, the config is now updated clientside when the data are fetched after a save. [Task-5420762](https://www.odoo.com/odoo/project/966/tasks/4655907/project.task/5420762) [opw-5223507](https://www.odoo.com/odoo/project/49/tasks/5223507) Forward-Port-Of: odoo/enterprise#117816 Forward-Port-Of: odoo/enterprise#113318
3 changes
Resolved issues and error corrections
This update resolves an issue that prevented users from creating bank accounts when a falsy value (like empty string) was entered for the proxy type (CPF/CNPJ or Random Key). The fix ensures the validation process handles these values correctly, preventing a traceback and allowing successful bank account creation. This improves the reliability of the BR accounting module.
Original PR description
Creating a bank account with a falsy proxy value generates a traceback. Steps to reproduce the error: - Install ``l10n_br`` module with demo data - Switch to BR Company - Go to Contacts >…
Creating a bank account with a falsy proxy value generates a traceback. Steps to reproduce the error: - Install ``l10n_br`` module with demo data - Switch to BR Company - Go to Contacts > Configuration > Bank Accounts > Create a new bank account > Add any value as Account Number > Account Holder: BR Company > Proxy Type: CPF/CNPJ(BR) or Random Key (BR) > Save Traceback: ```py InvalidFormat: The number has an invalid format. ``` ```py TypeError: 'bool' object is not iterable ``` https://github.com/odoo/odoo/blob/132f042ca14012877f608783b57a0ca9c4e565f3/addons/l10n_br/models/res_partner_bank.py#L38-L45 For ``CPF/CNPJ`` validation, calling ``check_vat_br`` with a falsy proxy value raises a traceback. https://github.com/odoo/odoo/blob/132f042ca14012877f608783b57a0ca9c4e565f3/addons/l10n_br/models/res_partner_bank.py#L56-L61 For ``Random Key`` validation, ``re.fullmatch`` expects a string value, but receives ``False``, leading to a traceback. sentry-7488238698 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where bank statement matching was incorrectly preventing multi-step reconciliation flows for liquidity and transfer accounts. The fix limits the matching filter to receivable and payable accounts, restoring the ability to accurately reconcile complex payment sequences like payouts through internal transfers.
Original PR description
Commit e2a9f3bfbb8a excludes from the bank statement matching domain any AML whose source statement line is already reconciled, to prevent false-positive label matches on past manual counterparts. However, the filter is applied to every account type, which breaks legitimate multi-step reconciliation flows on liquidity / transfer accounts (e.g. payout -> internal transfer account -> destination bank). After the first statement line is reconciled, the transfer-account AML is no longer offered as a candidate for the destination bank line; the line falls back to the suspense account and the AML is also invisible in "Match Existing Entries". Scope the new filter to receivable / payable accounts only, which is the case the original commit was actually guarding against. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#265653
This update fixes an issue where users without VAT numbers could inadvertently use Nemhandel and generate unnecessary OIOUBL XML files. The change ensures that Nemhandel functionality is only available to partners with valid VAT registration, streamlining processes and reducing potential errors. This improves data accuracy and compliance.
Original PR description
Users with no VAT number shouldn't be able to use Nemhandel and shouldn't have a OIOUBL xml generated. task-6196225