Daily updates from Odoo
Navigate
Branch
Friday, March 8, 2024
104 changes
27 changes
New functionality added to Odoo
This update enables Odoo users in Brazil to accept payments via Pix, a popular instant payment system developed by the Central Bank. The addition of static Pix code support streamlines the payment process, leveraging existing bank apps and ensuring compatibility with major Brazilian banks. Portuguese translations and thorough testing have been completed, enhancing the user experience.
Original PR description
This is a standard developed by the Central Bank of Brazil and provides QR codes (among other things) that allow customers to pay via their bank app. It's popular and usage keeps increasing [1]. Pix…
This is a standard developed by the Central Bank of Brazil and provides QR codes (among other things) that allow customers to pay via their bank app. It's popular and usage keeps increasing [1]. Pix codes [2] are BR codes [3] which are based on EMV QR codes. This commit adds support for static Pix codes. These contain all the info needed to make a payment. Dynamic Pix codes are more complex and not supported. Two validators were used to verify correctness [4][5]. The resulting Pix codes were also tested with the Caixa, Nubank and Itau bank apps (thanks to INGO!). Portuguese translations provided thanks to MADI. This will be merged into l10n_br in master. [1] https://www.bcb.gov.br/en/financialstability/pixstatistics [2] https://www.bcb.gov.br/content/estabilidadefinanceira/pix/Regulamento_Pix/II_ManualdePadroesparaIniciacaodoPix.pdf [3] https://www.bcb.gov.br/content/config/Documents/BR_Code_MANUAL_Version_2_May_2020.pdf [4] https://pix.nascent.com.br/ [5] https://openpix.com.br/qrcode/scanner/ task-3669412 Forward-Port-Of: odoo/odoo#156211
Enhancements to existing features
This update enhances the visual appearance of the payment form within the customer portal. The changes make the form more user-friendly, improving the overall customer experience when making payments. This is a simple visual improvement designed to streamline the payment process.
Original PR description
Improve visual of payment form in customer portal task-3640114 backport of odoo/odoo#150919 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156079
This update adjusts Luxembourg's VAT rates to reflect a 2023 temporary reduction. The previous VAT rates have been deactivated, but remain available for clients to use if needed. This ensures continued compliance with Luxembourg's tax regulations.
Original PR description
In Luxembourg, during the year 2023, the VAT rates were decreased by 1% temporarily. Now that we are in 2024, we need to deactivate the taxes added previously. We will not remove them so that client can still use them if needed. Task: 3635758 X-original-commit: eee565f --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156928
Resolved issues and error corrections
This update resolves a visual issue where the mandatory day color disappeared when hovering over it in the month view. The change adjusts the styling to ensure the correct color is consistently displayed, improving the user experience and visual clarity of the calendar.
Original PR description
Commit (1) introduced a fix on the mandatory day style. But it also creates another color issue: when we hover a mandatory day in the month view the mandatory color dissapears. This commit adapts the selector to handle this issue. (1): d75343d7d83ad56a7532038f01a2038c7e16f15f task-3758658 Part of task-3575827 | The issue | |--------| |  | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155201
This update fixes an issue where product names within Point of Sale sessions were consistently displayed in English, regardless of the selected language. The fix ensures that product names are correctly translated based on the user's chosen language setting, improving the user experience for international customers. This was a simple bug fix related to language context.
Original PR description
### Steps to reproduce: - Install **pos** app. - Add a new language (ex. french). - Switch to the new language. - Go to pos app, and open a new session. - Notice how the products' names are still in english. ### Investigation: - the source of the product name (`display_name`) is https://github.com/odoo/odoo/blob/de4627069ea2b45544e0c34ff5653cf5f28a1da1/addons/point_of_sale/static/src/app/screens/product_screen/product_screen.xml#L49 - which is computed by `_compute_display_name()` method in https://github.com/odoo/odoo/blob/de4627069ea2b45544e0c34ff5653cf5f28a1da1/addons/product/models/product_product.py#L465 - However the context of the `product.product` provided only contains `display_default_code` lacking `lang` needed for translating the name. opw-3760448
This update corrects an issue where Saudi invoices weren't being validated correctly due to timezone differences. The fix ensures that the invoice date is accurately compared, regardless of the user's location. This prevents invoices from being incorrectly flagged and ensures proper compliance with Saudi regulations.
Original PR description
Steps to reproduce ------------------ * install `l10n_sa_edi` * switch to a Saudi company * make sure user timezone is Asia/Riyadh * create and post an invoice between these time from 12:00 to 3:00 Cause ----- EDI Invoice could be validated closes odoo/odoo#155363 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#155895
This update resolves a discrepancy in invoice tax calculations, specifically when simulating EPD lines. The fix ensures that tax calculations are correctly applied by using the commercial partner instead of the partner ID during the simulation process, resulting in accurate tax totals.
Original PR description
Set 'Rounding Method' to 'Round globally' Set 'Cash Discount Tax Reduction' to 'Always (upon invoice)' Create a Payment term with 1% discount if paid before 30 days Create a company partner with child contact Create an invoice: - Add as partner the company partner (parent contact) or no contact at all (makes no difference) - Add a line with product 420.99, tax 21% not included - Add the payment term Tax total will show 87.52 Add the child contact as partner (set again payment terms if needed) Issue: Tax total will show 87.53 This occurs because, when simulating the not yet stored epd vals, we create the line using the `partner_id` and not the commercial partner. Then, when tax amounts are aggregated and rounding errors are managed the partner is used as grouping key to retrieve vals, so we don't fix the rounding error correctly opw-3661210 Forward-Port-Of: odoo/odoo#154174
This update streamlines the order preparation process in the restaurant POS module. Previously, note changes would reset the order, and order stages weren't sorted by product category. Now, notes are updated directly, products are categorized, and the system only sends crossed-out lines to the next stage, improving efficiency and accuracy.
Original PR description
Behavior before the changes: - When a note was modified, it cancelled the old orderline and recreated it with the new note. - Products were not sorted by category in the order preparation display. - Clicking on the header of an order sent it directly to the next stage, regardless of whether lines were crossed out or not. - There were brackets around the order number. Behavior after changes: - When a note is modified, it is modified directly on the existing orderline. - Products are now sorted by category in the order. - Clicking on an order header sends only the crossed-out lines to the next stage. If no line is crossed out, the entire order is sent. - There are no longer any brackets around the order name. taskId: 3764317 enterprise PR: https://github.com/odoo/enterprise/pull/57385 Forward-Port-Of: odoo/odoo#155246
This update fixes an issue where report placeholders were incorrectly including irrelevant data, leading to report errors. The changes also cleaned up unused placeholders to improve report efficiency and clarity. This ensures purchase order reports are accurate and reliable.
Original PR description
Previous PR: odoo/odoo#135739 added in report placeholders for the sake of easier editing of reports with studio. Unfortunately it didn't check that these placeholders aren't printed with real records which results in junk being included in the report, so we add in conditions to avoid this situation. Also, since the report was already being edited, clean up some of the placeholders because they didn't make sense/ didn't do anything (e.g. the `address` values weren't used + already have a special placeholder in studio => remove them). --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156674
This update fixes a limitation where only one automation rule could be triggered for incoming messages on Helpdesk tickets. The change ensures that multiple rules can now be active for the same trigger, providing greater flexibility in automating helpdesk workflows. This improves the efficiency of automated responses and ticket management.
Original PR description
Steps to reproduce: - Install base_automation_hr_contract and helpdesk - Setup two automation rules with model "Helpdesk Ticket" and "On incoming message" as trigger - Create a ticket in helpdesk Issues: Traceback is shown because `_message_post` doesn't have the origin attributes. This is due to the closure being wrong as explained here: https://github.com/odoo/odoo/blob/e2ad568e6cd4de2d721149eb76d04f58c8510191/addons/base_automation/models/base_automation.py#L686-L691 Solution: Encapsulate the `_message_post` function definition, so that each times we patch message_post we patch it with a new function. This wasn't the case before since `_message_post` wasn't isolated. This solution is similar to the other method patched. https://github.com/odoo/odoo/blob/e2ad568e6cd4de2d721149eb76d04f58c8510191/addons/base_automation/models/base_automation.py#L711-L734 opw-3758851 Forward-Port-Of: odoo/odoo#155596
This update resolves an issue where users with stock manager permissions in Odoo were encountering errors when deactivating stock picking types within the Point of Sale module. The change adds a necessary security check to ensure that POS configuration access is properly controlled, preventing unauthorized modifications and improving stability. This ensures consistent POS functionality for all users.
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 Forward-Port-Of: odoo/odoo#154888
This update corrects a calculation error in the Gantt chart's progress bar, ensuring accurate representation of employee attendance and contract-related work. Previously, the progress bar didn't account for contract durations, leading to inaccurate visual displays. This fix improves the clarity and reliability of the Gantt chart for HR managers.
Original PR description
Currently the progressbar computation are not contract-aware, we fix this here task-3777971 Forward-Port-Of: odoo/odoo#156040
This update fixes a problem where taxes weren't correctly identified as changed after a fiscal localization reload, specifically when taxes lacked repartition lines. The fix ensures that changes to taxes with different repartition lines are properly detected, preventing incorrect updates to tax settings.
Original PR description
To reproduce: - Install l10n_it - Go in settings - Fiscal Localization => reload - Go to the taxes => You will find taxes with [old] prefix The issue comes that we want to consider that a tax has changed if it has different repartition lines. We don't consider taxes that are defined without repartition lines. The template will have no lines, but the compute on actual taxes will generate default ones. It then considers that the tax has changed. task-3777629 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156028
This update fixes a blurry image issue in the Odoo blog posts, specifically within dynamic snippets. The problem stemmed from how images were initially handled, leading to poor quality. The fix ensures all blog images are properly resized, resulting in clearer and more professional-looking blog posts.
Original PR description
Some templates are rendering the blog post cover in a very blurry way. It was not detected sooner because of a mix of: - The default blog posts img do not go through the `/web/image` route and are…
Some templates are rendering the blog post cover in a very blurry way. It was not detected sooner because of a mix of: - The default blog posts img do not go through the `/web/image` route and are not resized down / impacted - Some of the layout are working fine - For the problematic layouts, the problem gets worst when you select only one or two "Fetched Elements". Steps to reproduce: - Add an image on a blog post (you can just download the one on the PR, see at the end of this message) - Add a "Blog Posts" dynamic snippet on a page - Select "Card Layout" - By default, you'll see that the image is very blurry. If you select 2 (or 1) instead of 3 fetched elements, it will get even worst. Note that it's like that since forever, when it was introduced with https://github.com/odoo/odoo/commit/3c0d98bcd8adf9325ee3497eb8d25ec7f904d6a5 opw-3771992 Image to test:  Forward-Port-Of: odoo/odoo#156381
This update resolves a bug that occurred when closing recurring tasks in Odoo. The issue stemmed from a duplicate creation of follower records, leading to a validation error. The fix ensures that the creation process avoids this duplication by temporarily disabling automatic follower creation during recurring task updates.
Original PR description
to reproduce: ============= - make a task recureent - change its state to a closing one -> Validation Error Problem: ======== - when creating the next occurence, we insert the followers of the…
to reproduce: ============= - make a task recureent - change its state to a closing one -> Validation Error Problem: ======== - when creating the next occurence, we insert the followers of the original task in the new one, but it happens that we create a `mail_followers` twice which violates an SQL constraint of `mail_followers`. https://github.com/odoo/odoo/blob/ea170be9089ee6c784664475ac4ec1218d23dccd/addons/mail/models/mail_thread.py#L253-L262 the create method will create `mail_followers` for the task and as the condition that follows is truthy in this use-case `_insert_followers` will be called and create `mail_followers` again. - In previous versions we didn't face this issue because the creation of occurences was done by a cron, so the condition was never truthy thanks to `and self.env.user.active`. Solution: ========= to make sure the conditon stays falsy, we set `mail_create_nosubscribe` in context to `True` when creating the next occurence. opw-3742737 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156900 Forward-Port-Of: odoo/odoo#154927
This update ensures that tracking numbers displayed in the Point of Sale system now accurately match the information recorded in the backend. Previously, tracking numbers were inconsistent due to changes in the session ID. This fix improves data accuracy and provides a more reliable experience for users managing paid orders.
Original PR description
Before this commit, when loading paid orders, the tracking number would differ from the backend. This discrepancy was due to the fact that the `pos_session_id` was being changed to the current session. opw-3788982 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156733
The product search feature in the Point of Sale system has been optimized to handle large product databases more efficiently. By increasing the delay before search queries are triggered, we've reduced performance issues and improved the overall responsiveness of the system when users are searching for products.
Original PR description
Before this commit, searching for a product in the product screen was problematic when dealing with large databases. The search function was triggered too frequently, leading to performance issues. With this commit, I have increased the debounce time for the product search. This reduces the frequency of search operations when user is typing. opw-3788796 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156806
This update corrects a display issue where data from a secondary company (compB) was incorrectly shown on the accounting dashboard. The fix ensures that data is accurately reflected only for the user's designated main company (compB), resolving a potential confusion regarding company-specific financial information. This improves data clarity and accuracy for users managing multiple companies.
Original PR description
Setup 2 companies with a COA: compA & compB For compA, have a journal having some data Give you access to compA & compB but make sure compB is your main company => samples data are displayed on the accounting dashboard for the journal Setup 2 companies with a COA: compA & compB, compB being a branch of compA For compA, create a journal Add some data into this journal using compB Give you access to only compA => you should not be able to see the data from compA since the data belongs to compB Introduced by: https://github.com/odoo/odoo/commit/24789b2c906e71d347924bfa1bcc7d3ca77d8daf issue: 3722386 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156737 Forward-Port-Of: odoo/odoo#153641
This update allows individual company branches to set their own default tax rates within Point of Sale (POS). Previously, all branches used the same tax settings as the parent company. This change improves flexibility and accuracy for businesses with multiple locations.
Original PR description
Before this commit: When a company having branches, they uses the same taxes as the parent company, In POS settings, the default tax used a company domain which does not allow branch to change the default tax After this commit: A branch is allowed to change the default tax task-3775857 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#156434
This update resolves an issue where users without registration permissions would receive an access error when attempting to change the partner on a Sales Order. By using 'sudo,' the system now behaves consistently with other related processes, ensuring a smoother experience for all users. This prevents unexpected errors and maintains data integrity.
Original PR description
If the user doesn't have rights to registrations and tries to change the partner on a SO, this will raise an access error even if there's no registrations linked to the SO. We use sudo to be coherent with what is done in _update_registrations. 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#151920 Forward-Port-Of: odoo/odoo#151506
This update resolves an issue where POS users wouldn't be able to access the self-order mobile menu if they lacked access to the initial company setup. The fix ensures the correct company access settings are applied, preventing access errors when managing multiple companies within the POS system. This improves the user experience for businesses utilizing the self-order feature.
Original PR description
Before this commit, if the POS user didn't have access to the first company, an access error would be raised when accessing the self-order page. The steps to reproduce this issue are as follows: 1. Add another company and set up POS self-order. 2. Remove the other company from the Marc user. 3. Open the POS in the new company. 4. Try to access the mobile menu. This would result in an access error. The issue was that the first company existed in the `allowed_company_ids` in the context. To solve this, we need to correctly set the `allowed_company_ids` in the context. opw-3744500 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156357
This update fixes an issue where landed costs were incorrectly applied to the full MO quantity (1000) instead of the actual produced quantity (900). The change reflects a new definition of a field that now accurately tracks initial demand, ensuring landed costs are calculated correctly for partial production runs.
Original PR description
Steps to reproduce: - Create an MO qty = 1000 - Only produce 900 - Create a landed cost for that MO Bug: landed cost is applied on 1000 units instead of 900 starting V17 definition of the field (product_ty) has been changed to reflect the intial demand apply same fix as in: https://github.com/odoo/odoo/pull/137864/files#diff-d41327f63c4c3d8d369a3f8622f794aa03f79f5f93d9ec01dfa5c179fd8f31eaR159-R162 opw-3696385 Forward-Port-Of: odoo/odoo#156366
This update resolves a technical issue that prevented users from creating orderpoints when archived locations were involved. Previously, the system would throw an error (KeyError). Now, orderpoint creation correctly considers archived locations, ensuring accurate inventory calculations and preventing disruptions to the ordering process.
Original PR description
orderpoint creation should also consider archived location while building the domain or else users will be faced with a `KeyError` Description of the issue/feature this PR addresses: Fixes KeyError when creating orderpoints Current behavior before PR: Users are faced with a KeyError Desired behavior after PR is merged: KeyError is fixed --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156965 Forward-Port-Of: odoo/odoo#155397
This update fixes a bug where German businesses using the SKR03 fiscal localization were incorrectly flagged as not requiring VAT. The change ensures that fiscal positions with a VAT ID are automatically marked as requiring VAT, aligning with German tax regulations. This prevents potential errors and ensures accurate accounting for our German customers.
Original PR description
Steps to reproduce: - - Install the l10n_de package - Create and select a german company - Accounting > Configuration > Settings > Fiscal localization - Set: Deutscher Kontenplan SKR03 for the fiscal…
Steps to reproduce: - - Install the l10n_de package - Create and select a german company - Accounting > Configuration > Settings > Fiscal localization - Set: Deutscher Kontenplan SKR03 for the fiscal localization - Accounting > Configuration > Accounting > Fiscal Positions - Click on "Geschäftspartner EU (mit USt-ID)" (this fiscal position translates to "Business partner EU (with VAT ID)". Issue: The `vat_required` field of this fiscal position is False but sould be True as the fiscal position is "(with VAT id)". Cause of the issue: - The `vat_required` field is a Boolean of the account.fiscal.position model without defaut value nor compute method. As such it is interpreted as "False" when unset (just like any unset python boolean). Since the `vat_required` field is not set in the data file of the `l10n_de_skr03` localization for the "Geschäftspartner EU (mit USt-ID)" fiscal position, it will be interpreted as False. Fix: - We update the data file of the fiscal localization to the expected value opw-3721912 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156934 Forward-Port-Of: odoo/odoo#156444
This update fixes an issue where invoices imported through the l10n_it_edi module were consistently being added to the first company in a multi-company setup. Now, invoices are correctly imported into the company they belong to, ensuring accurate accounting records across all businesses.
Original PR description
When the Cron runs in a multi-company environment, all invoices imported only in first company. They should be imported in the company they belong to. Ticket link: https://www.odoo.com/web#model=project.task&id=3744537 opw-3744537 Forward-Port-Of: odoo/odoo#156462
Documentation and clarification updates
This pull request adds a signature for Gaurav Pandey, confirming he has signed a Contributor License Agreement (CLA). This ensures compliance with Odoo's open-source licensing and allows his contributions to be incorporated into the core Odoo platform. It's a standard legal step for all external contributors.
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 Forward-Port-Of: odoo/odoo#156919
This pull request updates the corporate legal agreement (CLA) signature documentation for VG&Co. This ensures compliance with our legal agreements and strengthens our legal protections. It's a routine update to maintain accurate legal records.
Original PR description
Corporate CLA Signature Forward-Port-Of: odoo/odoo#155971
24 changes
Enhancements to existing features
This update cleans up the VoIP module code by making parameter handling clearer, removing unused code references, and deleting unnecessary license comments. It helps keep the system easier to maintain and aligned with current coding standards, with no expected change for day-to-day users.
Original PR description
In this PR: ## [IMP] voip: make optional parameters explicit "Implicit Optionals" are prohibited by PEP 484. This commit adapts VoIP code to make them explicit. ## [IMP] voip: remove unused imports ## [IMP] voip: remove useless licence comments
Users now see a clearer warning when they try to preview or edit Excel (.xlsx) files in Documents Spreadsheet. This helps set expectations and reduces confusion before users take action on files that may need special handling.
Original PR description
## Description Enhanced the warning message for users attempting to preview or edit xlsx files. Task ID: [3746208](https://www.odoo.com/web#id=3746208&cids=2&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form)
Payroll and expense workflows are now better connected, with clearer links between payslips, expense reports, salary entries, and vendor bills. This helps users track reimbursements more easily, keeps related accounting entries aligned, and allows reported expenses to be removed from unpaid payslips when needed.
Original PR description
This aims to: - Improve UI/UX by adding smart buttons linking the models - Improve the entries (salary + vendor bill) generation and automatically reconcile the moves together - Add more links between the payslip and the report to sync states - This also make the hr_payroll_expense module auto installed - Adds the dependency to hr_payroll_account as it is required (also adding account_accountant in the dependencies) - Allow to remove a reported expense from unpaid payslips task-3482475
Field service teams can now access a Planning by Location view to group tasks geographically. This helps dispatchers schedule nearby interventions together, reducing travel time and improving route efficiency.
Original PR description
Allow users to group their tasks by location so that they can plan and regroup interventions in the same area, thus reducing traveling time. task-3608075
The helpdesk timesheet report has been updated to stay aligned with related reporting changes in the main Odoo platform. This helps keep exported or printed timesheet information consistent and easier to read for helpdesk work.
Original PR description
This commit adapts the template inherited according to the changes made in community PR. Community PR: https://github.com/odoo/odoo/pull/131021 task-3441573
This update converts Gantt view test suites to the newer Hoot testing framework across several business apps. It improves the reliability and maintainability of automated checks for planning, appointments, projects, attendance, and manufacturing scheduling without changing end-user features.
Original PR description
task-id: 3705027
Helpdesk now sends users directly to the specific Alias Domain setting when setup is needed. This reduces confusion in the general settings page and helps teams complete email alias configuration faster.
Original PR description
Before this commit, when the user has to define the alias domain in the main setting, a button in the helpdesk form view redirects him to the General settings but he could not know which field, he should set since there could have many fields displayed in the setting form view. This commit adds a context key `setting_default_alias_domain_id` to be able to filter the setting form view to only have that field when the General settings view is loaded. task-3614449
Resolved issues and error corrections
When a task or helpdesk ticket is moved to another project or team, draft timesheets now follow it automatically while approved timesheets remain unchanged. This keeps billing information consistent and warns users if the new project does not support timesheets.
Original PR description
> Description of the issue/feature this PR addresses: When a task/helpdesk_ticket contains non-validated timesheets and we change the task's project/helpdesk_team, we want the timesheets to follow…
> Description of the issue/feature this PR addresses: When a task/helpdesk_ticket contains non-validated timesheets and we change the task's project/helpdesk_team, we want the timesheets to follow the new project of the task. By doing that, the timesheets will follow the task's project and the SOL of those timesheets will be correctly based on the SOL set on the task linked. Tests are added to test this behavior. > Current behavior before PR: - When the project of a task/ticket gets modified, the timesheets associated to the task/ticket gets un-linked to the task/ticket no matter the validation status of the timesheets. > Desired behavior after PR is merged: When the user changes the project of a task/ticket with timesheets from the task/ticket form: - If there is at least 1 non-validated timesheet and the new project has not the timesheets feature enabled, raise an warning message to user, and allow the changes - Set the new project_id as the project of the non-validated timesheets - Validated timesheets don't get any changes, and keep their original project. [task-3669013](https://accounts.odoo.com/web#id=3669013&cids=1&menu_id=4720&action=333&active_id=4105&model=project.task&view_type=form) community PR: https://github.com/odoo/odoo/pull/153281 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Features or functions removed from Odoo
An outdated inventory accounting extension was removed because the dashboard it supported no longer exists. A redundant subscription sales reporting customization was also removed, simplifying maintenance without expected business impact.
Original PR description
#### [REM] stock_account_enterprise: remove stock_account_enterprise module The module extended stock.report with two fields used in dashboard. But this dashboard has been removed by https://github.com/odoo/enterprise/pull/31641/files#diff-cdc64cb14d8f3a57b35e2d827692ed64b5a9f359f4684b42a9041ef536f08e44. Then this module doesn't make sense anymore. #### [REM] sale_subscription: remove useless read_group() override https://github.com/odoo/odoo/pull/156325 https://github.com/odoo/upgrade/pull/5776
Code cleanup and technical improvements
Automated test steps in Knowledge and Web Studio were updated to use a newer, cleaner way of identifying embedded page content. This is an internal maintenance change that helps keep testing infrastructure simpler and easier to maintain, with no direct change for end users.
Original PR description
In this commit, we change some triggers in tours where en iframe is selected. For this, we use the :iframe HOOT pseudo-selector. These changes are made with a view to remove the getNodesFromSelector function in odoo/addons/web_tour/static/src/tour_service/tour_utils.js task~3600484
This update removes outdated internal module tags from Gantt-related files across appointment, attendance, HR, payroll, holidays, and work entry areas. It does not change business features or user workflows, but helps keep the codebase aligned with current development standards.
This update removes an outdated internal setting from spreadsheet cell evaluation. It simplifies the spreadsheet code without changing how users work with spreadsheets.
Original PR description
The command `EVALUATE_CELLS`'s `sheetId` is no longer used since many many versions.
This update simplifies how automated tours interact with embedded iframe content across Sign, Payroll test flows, and Studio report tests. It supports ongoing cleanup of internal testing code, reducing maintenance effort without changing user-facing business features.
Original PR description
In this commit, we change some triggers in tours where en iframe is selected. For this, we use the :iframe HOOT pseudo-selector. These changes are made with a view to remove the getNodesFromSelector function in odoo/addons/web_tour/static/src/tour_service/tour_utils.js task~3600484
Miscellaneous changes
Currently the progressbar computation are not contract-aware, we fix this here task-3777971 Forward-Port-Of: odoo/enterprise#57902
Original PR description
Currently the progressbar computation are not contract-aware, we fix this here task-3777971 Forward-Port-Of: odoo/enterprise#57902
Steps to reproduce: - Create two company San Francisco (SF) and Chicago (CH) - Make a service product, with "Subcontract Services" enabled on both company - For SF set CH as the vendor. - For CH set an external vendor - For both company enable "Inter-Company Transaction" and "Automatic Validation" - Enable subcontract services and set the first company as the vendor - Make a PO on SF and confirm it - An SO is created on CH Issue: A PO should be created on CH but we have nothing
Original PR description
Steps to reproduce: - Create two company San Francisco (SF) and Chicago (CH) - Make a service product, with "Subcontract Services" enabled on both company - For SF set CH as the vendor. - For CH set…
Steps to reproduce: - Create two company San Francisco (SF) and Chicago (CH) - Make a service product, with "Subcontract Services" enabled on both company - For SF set CH as the vendor. - For CH set an external vendor - For both company enable "Inter-Company Transaction" and "Automatic Validation" - Enable subcontract services and set the first company as the vendor - Make a PO on SF and confirm it - An SO is created on CH Issue: A PO should be created on CH but we have nothing. Solution: Remove the function override that would stop this behavior. This code is part of commit (https://github.com/odoo/enterprise/commit/7cb233575e6440cc02cc67f5d5e747c7d22ae183), this function restriction was needed to fix a flow. "Subcontract Services" wasn't company dependent at the time of the commit, meaning that if company CH didn't have a supplier we ran into an issue since we would try to confirm a PO without any vendor. Now that "Subcontract Servives" is company dependent this particular flow is now avoidable by the client (making it a mis-configuration instead of a bug). opw-3622278 Forward-Port-Of: odoo/enterprise#57964 Forward-Port-Of: odoo/enterprise#54316
Versions -------- - 16.0+ Steps ----- 1. Have SOL discounts enabled; 2. create a pricelist with a discount; 3. set Discount Policy to Show public price & discount; 4. create a quotation; 5. using the pricelist, add a product it's applicable to; 6. manually modify the discount; 7. in Other Info, add a Start Date. Issue ----- The manually modified discount was reset. Cause ----- The sale_subscription's override of `_compute_discount` adds `start_date` as a dependant field. W
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Have SOL discounts enabled; 2. create a pricelist with a discount; 3. set Discount Policy to Show public price & discount; 4. create a quotation; 5. using the pricelist, add a product it's applicable to; 6. manually modify the discount; 7. in Other Info, add a Start Date. Issue ----- The manually modified discount was reset. Cause ----- The sale_subscription's override of `_compute_discount` adds `start_date` as a dependant field. When no start date is at confirmation, it will be set to the current date, triggering a recomputation of discount fields. Solution -------- Add an `action_confirm` value to the context when confirming a subscription, and check for it in `_compute_discount` to avoid recomputing non-upsell line discounts. opw-3646915 Forward-Port-Of: odoo/enterprise#58022 Forward-Port-Of: odoo/enterprise#57222
Issue: - Open the Documents App. - Select any PDF and click splitPDF from the inspector. - Now from the top-left, try to toggle back to home by clicking precisely on the arrow. - We get a traceback. Reason: - link to the LOC from where the issue arises: https://github.com/odoo/enterprise/blob/705bed9b2c63227c36f42045903f490a5d287f1f/documents/static/src/owl/components/pdf_manager/pdf_manager.js#L1275 - The `ev.target` returns an `<svg>` element (the toggle arrow) when clicked d
Original PR description
Issue: - Open the Documents App. - Select any PDF and click splitPDF from the inspector. - Now from the top-left, try to toggle back to home by clicking precisely on the arrow. - We get a traceback.…
Issue: - Open the Documents App. - Select any PDF and click splitPDF from the inspector. - Now from the top-left, try to toggle back to home by clicking precisely on the arrow. - We get a traceback. Reason: - link to the LOC from where the issue arises: https://github.com/odoo/enterprise/blob/705bed9b2c63227c36f42045903f490a5d287f1f/documents/static/src/owl/components/pdf_manager/pdf_manager.js#L1275 - The `ev.target` returns an `<svg>` element (the toggle arrow) when clicked directly on it. - When clicked on the bottom right end of the toggle arrow, it returns the `<rect>/<g>` element. - Since neither the `<svg>/<rect>/<g>` element have a `click()` method, clicking directly on them results in a traceback. Fix: - We use the bootstrap class `pe-none` to disable the pointer-events inside the `<svg>` element. After this commit: - We successfully land on the HOME, when clicking on the arrow. The traceback no longer occurs after this fix. Task-3764120 Forward-Port-Of: odoo/enterprise#57514
When coming back to the time selection screen, from an error or through chevrons, the previously chosen resource (resource_selected_id in the url) was selected for 'Time then resource' in the resource dropdown, and at loading, also when computing available slots. In order to let the user choose their resource in that case, do not use the selected resource for time_resource types, nor for computing availabilities at first loading, nor to restrict the resource dropdown. Task-3603354 Forward
Original PR description
When coming back to the time selection screen, from an error or through chevrons, the previously chosen resource (resource_selected_id in the url) was selected for 'Time then resource' in the resource dropdown, and at loading, also when computing available slots. In order to let the user choose their resource in that case, do not use the selected resource for time_resource types, nor for computing availabilities at first loading, nor to restrict the resource dropdown. Task-3603354 Forward-Port-Of: odoo/enterprise#56586
[IMP] l10n_be_hr_contract_salary: improve salary configurator choices This commit includes improvement to the benefit selection. Implementing a logic where selecting "Private Bike" automatically disables the "Fuel Card" option and resets any entered amount to 0 Task-3749460 Forward-Port-Of: odoo/enterprise#58079 Forward-Port-Of: odoo/enterprise#56936
Original PR description
[IMP] l10n_be_hr_contract_salary: improve salary configurator choices This commit includes improvement to the benefit selection. Implementing a logic where selecting "Private Bike" automatically disables the "Fuel Card" option and resets any entered amount to 0 Task-3749460 Forward-Port-Of: odoo/enterprise#58079 Forward-Port-Of: odoo/enterprise#56936
For resource appointments with Resource Then Time setting, when clicking on a day to select a slot, for instance on update of the slots when changing users, or when simply when selecting a day, the resource_selected_id is not added properly to the url as it should, hence not showing the selection in the details column in the /info screen. This is only due to not using the value of the select for the resource. Fix the issue by using the value of the resource dropdown if any. Task-36
Original PR description
For resource appointments with Resource Then Time setting, when clicking on a day to select a slot, for instance on update of the slots when changing users, or when simply when selecting a day, the resource_selected_id is not added properly to the url as it should, hence not showing the selection in the details column in the /info screen. This is only due to not using the value of the select for the resource. Fix the issue by using the value of the resource dropdown if any. Task-3603354 Forward-Port-Of: odoo/enterprise#56585
Forward-Port-Of: odoo/enterprise#58085
Original PR description
Forward-Port-Of: odoo/enterprise#58085
Before this commit, the appendix A had default value that were fill thanks to a hardcoded mapping. The user had zero control on this, we decided to use tags instead. What was done: - Put the tags in l10n_lu to be able to use it in the COA - Remove the mapping - Change the function to work with tags instead of the mapping task: 3646832 Forward-Port-Of: odoo/enterprise#54525
Original PR description
Before this commit, the appendix A had default value that were fill thanks to a hardcoded mapping. The user had zero control on this, we decided to use tags instead. What was done: - Put the tags in l10n_lu to be able to use it in the COA - Remove the mapping - Change the function to work with tags instead of the mapping task: 3646832 Forward-Port-Of: odoo/enterprise#54525
The owl key used was the id of the journal item, it is not unique in some cases of indirect linked aml (amls which don't have the partner of the report section but are reconciled with an aml which have this partner). An indirect aml can have multiple partial reconciliations with different amls from the same partner. Also the way odoo shows indirect aml in "Unknown partner" section is to duplicate all info shown except debit/credit/balance from origin aml (so this include aml.id). To suppor
Original PR description
The owl key used was the id of the journal item, it is not unique in some cases of indirect linked aml (amls which don't have the partner of the report section but are reconciled with an aml which have this partner). An indirect aml can have multiple partial reconciliations with different amls from the same partner. Also the way odoo shows indirect aml in "Unknown partner" section is to duplicate all info shown except debit/credit/balance from origin aml (so this include aml.id). To support those cases, we now use a markup with the id of partial reconcile to produce unique keys. When the aml is not an indirect aml, this markup is set to 0. Steps to reproduce: 1/ Create an invoice with partner 2/ Create a MISC entry without partner for the same amount 3/ Reconcile both 4/ Go to partner ledger for the right period + unfold all => Traceback opw-3700478 Forward-Port-Of: odoo/enterprise#57105
Adds a new module that prevents an Avatax fiscal position from being applied on Amazon orders. This is done to avoid calculating and filing taxes twice from sales synced through the Amazon connector. task-3701878 Forward-Port-Of: odoo/enterprise#56518
Original PR description
Adds a new module that prevents an Avatax fiscal position from being applied on Amazon orders. This is done to avoid calculating and filing taxes twice from sales synced through the Amazon connector. task-3701878 Forward-Port-Of: odoo/enterprise#56518
49 changes
New functionality added to Odoo
This update adds support for Internal Reverse Charge invoicing in Italy, a tax compliance requirement for certain business transactions. The system now automatically handles the correct tax classifications, generates required tax documents (TD16, TD17, TD18) for submission to Italian tax authorities, and ensures proper invoice documentation with legally-required notes. This enables Italian businesses to comply with reverse charge regulations for transactions involving scrap, gold, and other exempt categories.
Original PR description
Add support for Internal Reverse Charge invoicing flows in Italy. - Add 0% sale taxes and purchase taxes targeting `VJ` grids in `l10n_it` for every Tax Exemption Reason involved (Scrap, Gold...) -…
Add support for Internal Reverse Charge invoicing flows in Italy.
- Add 0% sale taxes and purchase taxes targeting `VJ` grids in `l10n_it` for every Tax Exemption Reason involved (Scrap, Gold...)
- Add a Fiscal Position (equivalent to the Belgian "CoContractant" one) mapping the sale tax and purchase taxes to their Reverse Charge corresponding taxes. Those fiscal positions all have a different law-required note (with the law reference) that has to be printed on the PDF invoice through Odoo standard mechanisms.
- The way we compare the invoice features and each document type requirements has been revised and expanded for the tax_tags sets case. Now it should also avoid comparisons after the first failure, instead of doing all the comparison anyway.
- Imported vendor bills that have `TD16, TD17, TD18` now have their 0% reverse charge sale taxes converted to their purchase 22% VAT reverse charge corresponding tax impacting `VJ` tax grids, following this mapping:
```
Sale tax examption reason -> VJ grid targeted by purchase tax
N3.2: VJ3
N3.3: VJ1
N6.1: VJ6
N6.2: VJ7
N6.3: VJ12
N6.4: VJ13
N6.5: VJ14
N6.6: VJ15
N6.7: VJ16
N6.8: VJ17
```
- Vendor bills that have taxes targeting grids `VJ6, VJ7, VJ8, VJ12, VJ13, VJ14, VJ15, VJ16, VJ17` are exported as Tax Integrations XMLs to be sent to the Tax Agency with the document type `TD16`
- Vendor bills that have taxes targeting grid `VJ3` are exported as Tax Integrations XMLs to be sent to the Tax Agency with the document type `TD17`
- Vendor bills that have taxes targeting grid `VJ9` are exported as Tax Integrations XMLs to be sent to the Tax Agency with the document type `TD18`
Link: https://www.odoo.com/web#model=project.task&id=3724926
task-3724926This update adds support for Pix, a popular Brazilian payment standard that uses QR codes. Customers can now pay directly through their bank apps by scanning Pix QR codes generated in Odoo. The feature supports static Pix codes and has been tested with major Brazilian banks (Caixa, Nubank, and Itau).
Original PR description
This is a standard developed by the Central Bank of Brazil and provides QR codes (among other things) that allow customers to pay via their bank app. It's popular and usage keeps increasing [1]. Pix…
This is a standard developed by the Central Bank of Brazil and provides QR codes (among other things) that allow customers to pay via their bank app. It's popular and usage keeps increasing [1]. Pix codes [2] are BR codes [3] which are based on EMV QR codes. This commit adds support for static Pix codes. These contain all the info needed to make a payment. Dynamic Pix codes are more complex and not supported. Two validators were used to verify correctness [4][5]. The resulting Pix codes were also tested with the Caixa, Nubank and Itau bank apps (thanks to INGO!). Portuguese translations provided thanks to MADI. This will be merged into l10n_br in master. [1] https://www.bcb.gov.br/en/financialstability/pixstatistics [2] https://www.bcb.gov.br/content/estabilidadefinanceira/pix/Regulamento_Pix/II_ManualdePadroesparaIniciacaodoPix.pdf [3] https://www.bcb.gov.br/content/config/Documents/BR_Code_MANUAL_Version_2_May_2020.pdf [4] https://pix.nascent.com.br/ [5] https://openpix.com.br/qrcode/scanner/ task-3669412
Enhancements to existing features
This update significantly improves the speed of tax mapping calculations in the accounting system. The change optimizes how taxes are processed during financial operations, making the system 6 times faster for these calculations. This is especially important during system upgrades and when processing large volumes of financial data, reducing processing time from hours to minutes.
Original PR description
Context: upgrade script calling `recompute_fields(cr, "sale.subscription.line", ["price_subtotal"])`. It was noticed that this update step runs a long time and is not limited by the DB, but…
Context: upgrade script calling `recompute_fields(cr, "sale.subscription.line", ["price_subtotal"])`. It was noticed that this update step runs a long time and is not limited by the DB, but CPU-limited in python. Profiling the code showed that 94% of the execution time is spent in the `filtered()` call in `map_tax()` of model `account.fiscal.position` during this upgrade. The profile also shows that this whole code path effectively creates deeply nested loops, leading to 3.6 **billion** calls to the `lambda` passed to `filtered()` with only ~4k rows on model `sale.subscription.line` (upg-1218044). The idea of this improvement is to - by the grace of `read_group()` - build a dict of ids that maps tax_src_id to dest_ids outside of the loop over `taxes` and then build the result only through lookups from that dict, reducing the loop nesting by two levels. Using cProfile again, it shows that the average runtime of `map_tax()` is ~6x faster with the patch (16.7ms vs. 2.8ms). For above cited upgrade, the process is no longer CPU limited and the runtime of this step is reduced from ~8h to ~2.5h, which is significant enough to be relevant for upgrades. Considering this code is unchanged on branches up to `master`, this should also reduce response times in normal operation, when recomputations involving multiple calls to `map_tax()` are triggered by user action. Forward-Port-Of: odoo/odoo#151455
This update enhances the HR Attendance module to use high-accuracy geolocation when employees check in or out. By enabling more precise location tracking, the system can better verify that employees are at the correct location during attendance registration, improving the reliability of attendance records.
Original PR description
task-3764355
Resolved issues and error corrections
This fix resolves an error that occurred when users tried to open the Customer Statements report for editing in Web Studio. The issue was caused by missing context data during report initialization. The fix ensures the report can be opened properly by using alternative data when context is not available.
Original PR description
This issue occurs when the customer tries to open the Statements report using studio, at that time error will be generated. step to reproduce- - Install the `Accounting Customer Statements & Studio`…
This issue occurs when the customer tries to open the Statements report using studio, at that time error will be generated.
step to reproduce-
- Install the `Accounting Customer Statements & Studio`
- Open the Accounting.
- Go to Customers Menu > Customers > open any record.
- Click on the web_studio button > Reports.
- Open the `Customer Statements`.
- Error will be generated.
sentry traceback-
```
KeyError: 'context'
File "odoo/http.py", line 2157, in __call__
response = request._serve_db()
File "odoo/http.py", line 1732, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "odoo/service/model.py", line 133, in retrying
result = func()
File "odoo/http.py", line 1759, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 1960, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "addons/website/models/ir_http.py", line 235, in _dispatch
response = super()._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 207, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 722, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "home/odoo/src/enterprise/17.0/web_studio/controllers/report.py", line 351, in load_report_editor
report_qweb = self._get_report_qweb(report)
File "home/odoo/src/enterprise/17.0/web_studio/controllers/report.py", line 441, in _get_report_qweb
render_context = report._get_rendering_context(report, [0], {"studio": True})
File "home/odoo/src/enterprise/17.0/web_studio/models/ir_actions_report.py", line 44, in _get_rendering_context
ctx = super()._get_rendering_context(report, docids, data)
File "addons/stock/models/ir_actions_report.py", line 8, in _get_rendering_context
data = super()._get_rendering_context(report, docids, data)
File "odoo/addons/base/models/ir_actions_report.py", line 930, in _get_rendering_context
data.update(report_model._get_report_values(docids, data=data))
File "home/odoo/src/enterprise/17.0/l10n_account_customer_statements/report/customer_statements.py", line 11, in _get_report_values
docs = self.env['res.partner'].browse(data['context']['active_ids'])
```
[1]-https://github.com/odoo/enterprise/blob/661249d3ed4cbcbeff4ed96f5cbc31d5307d55e2/l10n_account_customer_statements/report/customer_statements.py#L11
This error occurs because the context[1] hadn't been prepared when the statement was opened.
after this commit, Should the context not be prepared, The `docids` will be passed to open the statement.
sentry-4721784639Fixed the positioning of the SLA Deadline filter in the Help Desk search interface. The filter was incorrectly appearing under Properties instead of being grouped with the Create Date filter. This improves the user experience by organizing related date filters together in a more logical way.
Original PR description
-master -saas-17.1 Steps to reproduce: - Open Help Desk app - Open any help-desk team - Click on search bar on the top Issue: - The issue here is that the SLA deadline filter in under properties which is separated and should be under Create Date filter Cause: - The SLA Deadline is added newly into the XML file but the field above i.e, Create Data is used as an Xpath(Field as an Xpath) to add a separator in a inherited record causing the the filter to be displaced Solution: - Changing the Xpath(Field as an Xpath) as SLA DeadLine allows the Properties filter to be added and SLA Deadline to be under Create Date Filter task-3707563
This fix resolves an issue where users couldn't edit product quantities in the catalog when accessing it from Field Service tasks. The problem occurred when multiple tasks referenced the same product—the system was incorrectly computing quantities from all tasks instead of just the current one, making products read-only. Now the catalog correctly shows editable quantities based on the specific task being viewed.
Original PR description
Steps to reproduce: - - Create an SO with two lines containing the product “Field Service” - Confirm the SO > 2 fsm tasks are created - Open the first task > access catalog via the `Products`…
Steps to reproduce: - - Create an SO with two lines containing the product “Field Service” - Confirm the SO > 2 fsm tasks are created - Open the first task > access catalog via the `Products` smartbutton - Add any product to the SO. - Open the second task > access catalog via the `Products` smartbutton - Add the same product to the SO. - Open the first task > access catalog via the `Products` smartbutton - Try to add more of that product **IMPOSSIBLE : “You can’t edit this product in the catalog”** Cause of the issue: - The way the catalogue is computed was refactored between 16.4 and 17.0 see: odoo commit bc01c7bcec974ee095f5855f225667645ef40213 The above situtation is not yet handled by this refactoring. In 16.4, since the catalogue was acceced from the task linked to the Field service, the quantities it displayed were computed with respect to that task. However, in 17.0 the quantities appearing in the catalogue are computed from the main SO containing both `Field services` SOL instead of being computed contextually from the task they are linked to. To be more precise: - When clicking on the smart button, the quantities appearing in the calatalogue are computed by the `_get_product_catalog_order_line_info`. This method starts by grouping the SOL referencing each product of the catalogue using the `_get_product_catalog_record_lines`: https://github.com/odoo/odoo/blob/c7f982774654459a2db6decd6ae1948e05e7d622/addons/product/models/product_catalog_mixin.py#L91-L92 https://github.com/odoo/odoo/blob/c7f982774654459a2db6decd6ae1948e05e7d622/addons/sale/models/sale_order.py#L1823-L1829 But here is the problem, since both SOL were able to reference the same product of the catalogue the product of the catalog will be set to 'readOnly' here (because `self` will contain both SOL): https://github.com/odoo/odoo/blob/c91ffa3bdbff845088111bc3036500c2c03fc357/addons/sale/models/sale_order_line.py#L1222-L1227 Hence, we will not be able to edit its value from the catalogue: https://github.com/odoo/odoo/blob/c91ffa3bdbff845088111bc3036500c2c03fc357/addons/product/static/src/product_catalog/order_line/order_line.xml#L18-L20 Fix: - As discussed with the PO of the Field Service module (see conversation of the ticket), the catalogue should be computed contextually using the task from which we access it and not from all tasks referring to that product in the main SO. Doing so will solve the problem since only one SOL will be associated to that product of the catalogue and the product will be set to `'readOnly' : False`: https://github.com/odoo/odoo/blob/c91ffa3bdbff845088111bc3036500c2c03fc357/addons/sale/models/sale_order_line.py#L1212-L1216 opw-3748833 ---
This fix corrects how payment policies are assigned to Mexican invoices (CFDI v4.0) to comply with official tax regulations. Previously, invoices with due dates later than the invoice date were incorrectly marked as immediate payment (PUE) instead of deferred payment (PPD). The update ensures invoices are now correctly classified based on actual payment terms and method specifications.
Original PR description
**Incorrect Payment Policy Calculation for CFDI v4.0** Impacted versions: - 17.0 **Current behavior:** When an invoice is created with a due date that is later than the invoice date, yet still within the same month, the system incorrectly assigns a payment policy of 'PUE'. This issue persists even when specific invoice payment terms are indicated. **Expected behavior:** According to [Anexo 20](http://omawww.sat.gob.mx/tramitesyservicios/Paginas/documentos/Anexo_20_Guia_de_llenado_CFDI.pdf), [Rule 2.7.1.39](http://omawww.sat.gob.mx/normatividad_RMF_RGCE/Paginas/documentos2024/rmf/rmf/RMF_2024-29122023.pdf) as well as rule 2.7.1.32 (same link as rule 2.7.1.39) an invoice must be assigned a payment policy of 'PPD' if payment will not be made on the day of issuance, or if the method of payment is not specified.
Fixed an issue where users couldn't properly select their preferred resource when returning to the time selection screen in appointment scheduling. Previously, a pre-selected resource would be automatically chosen, preventing users from changing it. Now users can freely select their resource when booking appointments with the 'Time then resource' option.
Original PR description
When coming back to the time selection screen, from an error or through chevrons, the previously chosen resource (resource_selected_id in the url) was selected for 'Time then resource' in the resource dropdown, and at loading, also when computing available slots. In order to let the user choose their resource in that case, do not use the selected resource for time_resource types, nor for computing availabilities at first loading, nor to restrict the resource dropdown. Task-3603354 Forward-Port-Of: odoo/enterprise#56586
This fix resolves a crash that occurred when users tried to delete a newly added product line from a batch transfer in the barcode app. The issue happened because the system tried to access information about a product line after it had been removed, causing an error. The fix adds a simple check to ensure the product line still exists before trying to access its details.
Original PR description
Steps to reproduce ================== - Go to the barcode app - Click on "Batch transfers" - Open a record - Add a new product and confirm - Click on the pencil next to the newly added product - Click on the delete button => `Cannot read properties of undefined (reading 'suggested_package')` Cause of the issue ================== When deleting a line, it is removed from the state [0] Solution ======== We simply need to check that the line exists --- [0]: https://github.com/odoo/enterprise/blob/5ef4a85febcde0a690a71cb1886a8a74daf31f47/stock_barcode/static/src/models/barcode_model.js#L390 opw-3688415 Forward-Port-Of: odoo/enterprise#58201 Forward-Port-Of: odoo/enterprise#57691
This update fixes two issues in the Knowledge app: portal users can now properly view embedded kanban boards in published articles without errors, and the Share Wizard no longer displays unnecessary separators when articles have no members. These fixes improve the user experience when sharing and viewing knowledge articles across different user types.
Original PR description
**Current behavior before this PR:** - Create 1 article that has an embedded kanban and 1 article inside a kanban(both articles are published). Now if the user opens this article from another user - member/portal, the user gets an error like 'Something went wrong'. - When an article has no members, the separator appears under the Shareable URLs section in the Share Wizard. **Reason:** - Access to the Kanban stage was only for the user who had access to that article, there was no condition that the stage was shown to the member/portal user if the article was published and the article was an item article. - There was no condition for not showing a separator when that article had no members. **Desired behavior after this PR:** - Kanban will appear properly with read access to the portal if the article is published. - If there is no member then the separator will not appear. **Task**-3486083 Forward-Port-Of: odoo/enterprise#56230
The "insert in spreadsheet" button in pivot views was incorrectly showing a tooltip with "0" when active. This fix removes the unwanted tooltip, which should only appear when the button is disabled due to duplicate grouping options. The update also removes redundant test code that was duplicating existing test coverage.
Original PR description
The button "insert in spreadsheet" added in the pivot view would display a tooltip of "0" when the button was active. The tooltip was only meant to be present when the button was disabled due to the presence of duplicated group bys in the pivot. This revision fixes the tooltip presence on the button and also removes a test that: - had a description that did not match the actual test - was in fact testing the same behaviour as another test -> useless redundancy Task: 3790072 Forward-Port-Of: odoo/enterprise#58297 Forward-Port-Of: odoo/enterprise#58160
This fix prevents manually entered discounts from being automatically reset when confirming a subscription order. Previously, when a start date was automatically set during confirmation, it would trigger an unintended recalculation of discount fields, overwriting any manual adjustments made by users. The fix protects discount values from being recomputed during the confirmation process.
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Have SOL discounts enabled; 2. create a pricelist with a discount; 3. set Discount Policy to Show public price & discount; 4. create a quotation; 5. using the pricelist, add a product it's applicable to; 6. manually modify the discount; 7. in Other Info, add a Start Date. Issue ----- The manually modified discount was reset. Cause ----- The sale_subscription's override of `_compute_discount` adds `start_date` as a dependant field. When no start date is at confirmation, it will be set to the current date, triggering a recomputation of discount fields. Solution -------- Add an `action_confirm` value to the context when confirming a subscription, and check for it in `_compute_discount` to avoid recomputing non-upsell line discounts. opw-3646915 Forward-Port-Of: odoo/enterprise#58022 Forward-Port-Of: odoo/enterprise#57222
This fix corrects how the system identifies invoices by disabling layout-based matching for customer invoices. The layout detection feature was incorrectly being used to identify customers, when it should only identify suppliers. This change ensures the feature works correctly by limiting it to vendor bills only, improving invoice processing accuracy.
Original PR description
The idea behind this matching is that invoices emitted by the same supplier will often look very much alike and thus share the same layout. Using the detected layout to identify the customer of a customer invoice doesn't make sense since the layout only identifies the supplier of the invoice. This feature should only be used on vendor bills. Forward-Port-Of: odoo/enterprise#58294
Timesheets added to helpdesk tickets now correctly inherit the commercial partner information from the ticket itself, rather than leaving it blank. This ensures consistent behavior with how timesheets work in regular projects and improves billing accuracy for helpdesk-related work.
Original PR description
Issue: ------ In the helpdesk application, when a timesheet is added to a helpdesk ticket, it does not have a commercial partner (we can add the field with studio to see this behaviour). There may be one if a commercial partner exists for the helpdesk project. This behaviour is contradictory to that found in project. Solution: --------- Add the `helpdesk_ticket_id` field invisibly in the view so that this field is in the fields to be updated with the onchange. It will be correctly updated during the onchange. Override the compute method to obtain the `commercial_partner_id` field in order to take the commercial partner from the helpdesk ticket and not from the task. opw-3759824 Forward-Port-Of: odoo/enterprise#58214 Forward-Port-Of: odoo/enterprise#58043
This fix resolves an issue where users without specific permissions to event registrations would encounter an access error when trying to change the partner on a sales order, even if no registrations were linked to that order. The change applies proper permission handling to prevent unnecessary access restrictions.
Original PR description
If the user doesn't have rights to registrations and tries to change the partner on a SO, this will raise an access error even if there's no registrations linked to the SO. We use sudo to be coherent with what is done in _update_registrations. 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#151782 Forward-Port-Of: odoo/odoo#151506
This update fixes a memory issue in the delivery module that occurred when processing large numbers of stock movements. The system now retrieves only the necessary data instead of loading everything into memory, resulting in faster processing times (27% improvement) and preventing crashes when handling thousands of records.
Original PR description
compute_packages method fetches all columns for stock_move_lines and its result_package_id. If stock_move_lines are a big number, it causes memoryerror. Pre fetch only the required fields. Also its better to use _read_group then search count in a loop. ``` select COUNT(*) from stock_move_line +---------+ | count | |---------| | 2546604 | +---------+ ``` While fetching 4000 records. time before: 4.77s time after: 3.50s 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 resolves a crash that occurred when editing links in the website editor, particularly when double-clicking the "Contact Us" button. The issue was caused by a timing problem where the system tried to access link editing tools before they were fully loaded. The fix ensures the system waits for all components to be properly initialized before attempting to edit links.
Original PR description
Steps to reproduce: - Go to website (Homepage) > Switch to "Edit" mode. - double-click the "Contact Us" button in the header or keep clicking it many times > Traceback: Cannot read properties of…
Steps to reproduce: - Go to website (Homepage) > Switch to "Edit" mode. - double-click the "Contact Us" button in the header or keep clicking it many times > Traceback: Cannot read properties of undefined (reading 'find')... After converting the `linktools` widget to Owl in [1], the DOM element of the component [2] was retrieved in an async process after it was mounted, (some legacy code can trigger the instantiation of the `linktools` when its parent component is not in the DOM and `this.linkComponentWrapperRef.el` won't be returned, see: `Link` > `onMounted`). When double-clicking the link, This implementation will lead to a race condition where the `onWillUpdateProps()` (mainly triggered by the click to focus the URL input...) will try to access the DOM element from [2] before being correctly set in `onMounted()`. The goal of this commit is to fix this behaviour by simply waiting for `onMounted` changes to be done before doing any adaptation on the `linktools` DOM. [1]: https://github.com/odoo/odoo/commit/d7245d2abf528d093226c80e40975e63d61e8997 opw-3706902
When receiving electronic invoices through the Italian EDI system, documents were incorrectly assigned sequence numbers from the MISC journal instead of their proper journal type. This fix ensures that imported bills and other documents receive the correct sequence number based on their actual document type, improving invoice organization and tracking accuracy.
Original PR description
Currently, if you have an empty MISC journal and receive a document, that document will be assigned a MISC sequence, regardless of the actual document's type. ### Cause When a document is received, it is processed in two steps: 1. An empty account move is created and linked with the document. 2. The newly created move is populated with data extracted from the document. At stage 1, when the move is created, it is temporarily placed in the MISC journal. In the event that this journal is empty, a sequence is assigned to the move. Consequently, even if the move's journal is subsequently changed, the sequence remains unaltered. ### Fix Manually recompute the sequence when the move's type is set. opw-3663873
This fix corrects a bug where landed costs were being calculated based on the original planned quantity instead of the actual produced quantity. For example, if a manufacturing order planned to produce 1000 units but only 900 were actually produced, the landed cost would incorrectly be applied to all 1000 units. This update ensures landed costs are now properly applied only to the units that were actually produced.
Original PR description
Steps to reproduce: - Create an MO qty = 1000 - Only produce 900 - Create a landed cost for that MO Bug: landed cost is applied on 1000 units instead of 900 starting V17 definition of the field (product_ty) has been changed to reflect the intial demand apply same fix as in: https://github.com/odoo/odoo/pull/137864/files#diff-d41327f63c4c3d8d369a3f8622f794aa03f79f5f93d9ec01dfa5c179fd8f31eaR159-R162 opw-3696385
This fix resolves an error that occurred when POS users without access to the first company tried to use the self-order mobile menu. The issue was caused by incorrect company permissions in the system context. Users can now access the self-order page regardless of which company they have permissions for.
Original PR description
Before this commit, if the POS user didn't have access to the first company, an access error would be raised when accessing the self-order page. The steps to reproduce this issue are as follows: 1. Add another company and set up POS self-order. 2. Remove the other company from the Marc user. 3. Open the POS in the new company. 4. Try to access the mobile menu. This would result in an access error. The issue was that the first company existed in the `allowed_company_ids` in the context. To solve this, we need to correctly set the `allowed_company_ids` in the context. opw-3744500 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a bug in the Saudi electronic invoice system where invoices created during specific times (12:00 to 3:00) were incorrectly validated due to timezone handling. The fix ensures that invoice dates are properly compared while accounting for the user's timezone, preventing validation errors for Saudi companies.
Original PR description
Steps to reproduce ------------------ * install `l10n_sa_edi` * switch to a Saudi company * make sure user timezone is Asia/Riyadh * create and post an invoice between these time from 12:00 to 3:00 Cause ----- EDI Invoice could be validated closes odoo/odoo#155363 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#155895
This fix enables users to select a default temporary account when setting up Point of Sale accounting for branch companies. Previously, this option was unavailable for branch company users, limiting their ability to configure POS settings properly. Now branch companies have the same account selection capabilities as main companies.
Original PR description
**Before this PR:** When the user creates a branch company, the pos(accounting) setting does not allow the selection of a default temporary account for the user. **After this PR:** The user is allowed to choose a temporary account from the branch company. **Task**-3775873
This fix resolves an issue where users couldn't select sales orders when working with individual contacts within a company structure. The system was incorrectly filtering results by comparing company-level and individual-level contact identifiers. Now the correct contact information is used, allowing employees to properly record timesheets against their company's sales orders.
Original PR description
Steps to reproduce:
- Create a new company contact and add a contact inside that company
- Create two service product that are service with following config:
- Invoicing policy: Based on Timesheets
- Create on Order: Project & Task
- Make an SO for the contact inside the company with the two service in
the order
- Confirm the SO
- Click on the smart button "Recorded"
- Click on new
- Click on new line at the "Sale Order item" column
Issues:
The list display "No records"
Solution:
Make sure that we search with the correct attributes, before we were
trying to match partner_id and commercial_partner_id.
Although similar in our case they are not equal as commercial_partner_id
represent the company and partner_id represent the individual.
opw-3750939This fix resolves an issue where Italian EDI invoices were being imported into only the first company when the automated import process ran in a multi-company setup. Now invoices are correctly imported into their respective companies. This ensures proper invoice organization and accounting accuracy across multiple company entities.
Original PR description
When the Cron runs in a multi-company environment, all invoices imported only in first company. They should be imported in the company they belong to. Ticket link: https://www.odoo.com/web#model=project.task&id=3744537 opw-3744537
This fix allows company branch locations to set their own default tax rates in Point of Sale settings, instead of being forced to use the parent company's taxes. This gives multi-location businesses more flexibility to configure tax settings appropriate for each branch.
Original PR description
Before this commit: When a company having branches, they uses the same taxes as the parent company, In POS settings, the default tax used a company domain which does not allow branch to change the default tax After this commit: A branch is allowed to change the default tax task-3775857 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 corrects an issue where invoice tax totals were displaying incorrectly (87.53 instead of 87.52) when using child contacts as invoice partners. The problem occurred because the system wasn't properly tracking the correct partner information when calculating and rounding tax amounts. This ensures accurate tax calculations regardless of which contact level is used on an invoice.
Original PR description
Set 'Rounding Method' to 'Round globally' Set 'Cash Discount Tax Reduction' to 'Always (upon invoice)' Create a Payment term with 1% discount if paid before 30 days Create a company partner with child contact Create an invoice: - Add as partner the company partner (parent contact) or no contact at all (makes no difference) - Add a line with product 420.99, tax 21% not included - Add the payment term Tax total will show 87.52 Add the child contact as partner (set again payment terms if needed) Issue: Tax total will show 87.53 This occurs because, when simulating the not yet stored epd vals, we create the line using the `partner_id` and not the commercial partner. Then, when tax amounts are aggregated and rounding errors are managed the partner is used as grouping key to retrieve vals, so we don't fix the rounding error correctly opw-3661210 Forward-Port-Of: odoo/odoo#154174
The purchase dashboard was using a fixed date from September 2022 that no longer reflected current data. This fix updates the dashboard to automatically use today's date, ensuring the purchase and stock information displayed is always current and relevant to your business needs.
Original PR description
Replace the hardcoded date "09-15-2022" in the list domain by `context_today().strftime(\"%Y-%m-%d\")` The domain is now stringified since it contains a dynamic value which is not valid in a json file. Task: 3756934 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix enables branch companies in the point-of-sale system to use their parent company's fiscal position settings. Previously, branches were unable to access parent fiscal positions, which limited configuration flexibility. This change improves operational efficiency for multi-branch retail operations.
Original PR description
**Before PR:** - In the point-of-sale, when a company had branches, - The branch company was unable to use the fiscal position of its parent company. **After PR:** - The branch company can now use the fiscal position of its parent company in the point-of-sale. Task ID: 3775865
This fix corrects how project stages are displayed when creating subtasks from the portal. Previously, personal stages were incorrectly included in the stage options. Now only the relevant project stages are shown, making it easier for users to select the correct stage when creating subtasks.
Original PR description
When creating a sub-task from a task form view in portal, the domain of the stage should exclude personal stages and include only the one of the project. taskid:3551354 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#156580 Forward-Port-Of: odoo/odoo#142555
This fix corrects how the accounting dashboard displays financial data when your company has multiple branches or related companies. Previously, users could see data from companies they shouldn't have access to. Now the dashboard properly respects company access permissions, ensuring each user only sees data from companies they're authorized to view.
Original PR description
Setup 2 companies with a COA: compA & compB For compA, have a journal having some data Give you access to compA & compB but make sure compB is your main company => samples data are displayed on the accounting dashboard for the journal Setup 2 companies with a COA: compA & compB, compB being a branch of compA For compA, create a journal Add some data into this journal using compB Give you access to only compA => you should not be able to see the data from compA since the data belongs to compB Introduced by: https://github.com/odoo/odoo/commit/24789b2c906e71d347924bfa1bcc7d3ca77d8daf issue: 3722386 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153641
This fix resolves an error that occurred when stock managers tried to deactivate picking types without having access to point of sale settings. The system now properly handles permission checks so that stock managers can manage picking types independently without requiring point of sale configuration access.
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 Forward-Port-Of: odoo/odoo#154888
Fixed a bug in the website blog module where blog post redirects were keeping unnecessary extra parameters in the URL. The fix simplifies the redirect logic to avoid duplicate query parameters that were being added in an incorrect format, resulting in cleaner and more reliable blog post URLs.
Original PR description
Don't try to keep extra params and co. Keep it simple... Else we should pop from request.params `blog` and `post` keys because now they are converted as query param with the slug format: /blog/name-1/post-1?blog=blog.blog(1,)&question=blog.post(1,) Forward-Port-Of: odoo/odoo#156890
This update prevents companies from being archived if they are linked to a website. When a company associated with a website is archived, public users lose access to that website and encounter errors. This fix ensures websites remain accessible by blocking the archival of companies that power them.
Original PR description
This commit prohibits the archival of a company if it is associated with a website. opw-3749772 Forward-Port-Of: odoo/odoo#156470
Fixed an issue where technical codes in Italian electronic invoice XML templates were being translated into other languages. These codes have strict character limits and must remain unchanged for compatibility with the Italian Tax Agency and domestic systems. The fix ensures codes like "Exch.Rate" stay in their original form rather than being translated to alternatives like "Currency".
Original PR description
Codes like "Exch.Rate" in the Italian EDI XML template for invoices were translated. They shouldn't be, as they have pretty short char limit and it's risky to people change that. The XML users are either domestic or the Italian Tax Agency itself, so no point in translating "Divisa" into "Currency" anyway. Link: https://www.odoo.com/web#model=project.task&id=3627379 opw-3627379 Forward-Port-Of: odoo/odoo#156781 Forward-Port-Of: odoo/odoo#153111
This fix resolves a problem where taxes were incorrectly marked as outdated (with [old] prefix) when reloading fiscal localization settings. The issue occurred because the system was incorrectly detecting changes in grouped taxes that don't have repartition lines defined. Now the system properly recognizes when these taxes haven't actually changed, preventing unnecessary updates.
Original PR description
To reproduce: - Install l10n_it - Go in settings - Fiscal Localization => reload - Go to the taxes => You will find taxes with [old] prefix The issue comes that we want to consider that a tax has changed if it has different repartition lines. We don't consider taxes that are defined without repartition lines. The template will have no lines, but the compute on actual taxes will generate default ones. It then considers that the tax has changed. task-3777629 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156028
This fix prevents the system from incorrectly validating customers as valid Peppol participants when they don't have Peppol identification details (EAS or endpoint) configured. Previously, users could run verification on any customer in the list view, causing non-Peppol customers to appear as valid participants. Now verification only runs when proper Peppol details are present.
Original PR description
If a partner doesn't have peppol eas or endpoint set, we still go through with checking participant's registration. This is not an issue if checking on a partner form, as the Verify button is invisible without these details being filled in. However, in the partner list view the button is always visible and it is possible to run verification for non-peppol customers. As a result, all of them show up as valid Peppol participants. With this commit we only run verification if there are eas and endpoint details. opw-3784945 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156877
This update fixes a technical error that occurred when users created inventory reorder points if archived storage locations existed in the system. The system now properly handles archived locations during reorder point creation, preventing errors and allowing the process to complete successfully.
Original PR description
orderpoint creation should also consider archived location while building the domain or else users will be faced with a `KeyError` Description of the issue/feature this PR addresses: Fixes KeyError when creating orderpoints Current behavior before PR: Users are faced with a KeyError Desired behavior after PR is merged: KeyError is fixed --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156906 Forward-Port-Of: odoo/odoo#155397
Blog post cover images were displaying blurry when using the dynamic "Blog Posts" snippet with certain layouts, especially when showing fewer items. This fix improves the image sizing in the snippet templates to ensure blog post images display clearly and professionally on your website pages.
Original PR description
Some templates are rendering the blog post cover in a very blurry way. It was not detected sooner because of a mix of: - The default blog posts img do not go through the `/web/image` route and are…
Some templates are rendering the blog post cover in a very blurry way. It was not detected sooner because of a mix of: - The default blog posts img do not go through the `/web/image` route and are not resized down / impacted - Some of the layout are working fine - For the problematic layouts, the problem gets worst when you select only one or two "Fetched Elements". Steps to reproduce: - Add an image on a blog post (you can just download the one on the PR, see at the end of this message) - Add a "Blog Posts" dynamic snippet on a page - Select "Card Layout" - By default, you'll see that the image is very blurry. If you select 2 (or 1) instead of 3 fetched elements, it will get even worst. Note that it's like that since forever, when it was introduced with https://github.com/odoo/odoo/commit/3c0d98bcd8adf9325ee3497eb8d25ec7f904d6a5 opw-3771992 Image to test:  Forward-Port-Of: odoo/odoo#156381
This fix resolves an issue where duplicate exchange difference entries were being created in the stock accounting system when using multi-currency purchases with anglo-saxon accounting. The fix ensures exchange differences are properly created with correct conditions and reconciled in the right order, preventing duplicate journal entries and maintaining accurate financial records.
Original PR description
When mixing anglo-saxon accounting and multi-currency, it sometimes leads to incorrect AMLs in the stock-in account To reproduce the issue: (Company in USD) 1. Setup some currency rates: - Yesterday:…
When mixing anglo-saxon accounting and multi-currency, it sometimes leads to incorrect AMLs in the stock-in account To reproduce the issue: (Company in USD) 1. Setup some currency rates: - Yesterday: 1000 EUR = 4335.1 USD - Today: 1000 EUR = 4348.0 USD 2. Create an auto-avco product 3. (Yesterday) Buy one product at 1000 EUR and receive it 4. Deliver the product 5. Bill the PO 6. Open the journal items of stock-in account Error: The AML for the exchange difference has been created twice When posting the bill, it leads to `_generate_price_difference_vals` where we generate AML/SVL in case of price differences. There, we also generate such records in case of exchange difference. This is what we do in the above use case. However, the AML is wrongly encoded, we need to respect some specific conditions: https://github.com/odoo/odoo/blob/d780a2fc73259244411329027349fad1cb353f34/addons/account/models/account_move_line.py#L1773-L1779 Otherwise, the reconciliation process won't work correctly and will generate its own AMLs for the exchange difference (hence the above error). On top of that, to ensure a full reconciliation, we need to first reconcile the exchange diff AML with the bill one. This is what we are supposed to do in `/stock_account`: we split all stock-in AMLs into three recordsets: `correction_amls`, `invoice_aml`, `stock_aml`. However, we don't correctly isolate the correction AMLs. Therefore, we try to reconcile all AMLs at once, which will not work. Note: This commit brings a behaviour change since the amount currency of exch-diff AML will now be zero, as it should (again, see the comment of the code quoted above in the reconciliation process). This also explains why this commit modifies an existing test: comparing the `balance` and the `amount_currency` of such AML is incorrect. OPW-3544318 Forward-Port-Of: odoo/odoo#155421
This fix ensures that QR codes are included when receipts are reprinted in the Point of Sale system. Previously, reprinted receipts were missing QR codes, which could cause problems with receipt validation and scanning. This update restores full functionality for receipt reprints.
Original PR description
Before this commit, if a receipt was reprinted, the QR code was not included. This could lead to issues with receipt validation and scanning. opw-3763169 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A recent code update accidentally removed the ability to translate the "Save current search" option in the filters dropdown. This fix restores translation support for this feature, ensuring users in different languages can see this option in their preferred language.
Original PR description
Due to a refactor of the code in [1], the string "Save current search" in the filters dropdown was not translatable anymore. This commit fixes that, so it is translatable again. [1] 976491e01272336bc34abcdcec2718f83e19c5fc --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156915
This fix resolves a validation error that occurred when users tried to close recurring tasks in the Project module. The issue was caused by duplicate follower records being created when generating the next occurrence of a recurring task. The fix prevents this duplication by adjusting how followers are handled during task creation.
Original PR description
to reproduce: ============= - make a task recureent - change its state to a closing one -> Validation Error Problem: ======== - when creating the next occurence, we insert the followers of the…
to reproduce: ============= - make a task recureent - change its state to a closing one -> Validation Error Problem: ======== - when creating the next occurence, we insert the followers of the original task in the new one, but it happens that we create a `mail_followers` twice which violates an SQL constraint of `mail_followers`. https://github.com/odoo/odoo/blob/ea170be9089ee6c784664475ac4ec1218d23dccd/addons/mail/models/mail_thread.py#L253-L262 the create method will create `mail_followers` for the task and as the condition that follows is truthy in this use-case `_insert_followers` will be called and create `mail_followers` again. - In previous versions we didn't face this issue because the creation of occurences was done by a cron, so the condition was never truthy thanks to `and self.env.user.active`. Solution: ========= to make sure the conditon stays falsy, we set `mail_create_nosubscribe` in context to `True` when creating the next occurence. opw-3742737 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156900 Forward-Port-Of: odoo/odoo#154927
Fixed a bug in the online shop where clicking on a product tag would incorrectly select a product category if they shared the same ID number. The fix ensures each filter element has a unique identifier so customers can properly filter products by tags without unintended category selections.
Original PR description
To reproduce: ============= - create a `product.public.category` -> (id = 15 for example) - create a `product.tag` with same id as the created category - create two products, one with the category…
To reproduce: ============= - create a `product.public.category` -> (id = 15 for example) - create a `product.tag` with same id as the created category - create two products, one with the category and the other with the tag - go to the shop and make sure to have the categories positioned on left (by default they are on top) - select the tag (by clicking on the label not the checkbox) -> the category is selected Problem: ======== with this configuration the checkbox of the category has `id=15` attribute and the tag has `id=15` attribute too. so when we click on the tag label and thanks to the `for=15` attribute of the label, we will trigger click event on `input#15` which is the category checkbox because it's the first one in the DOM. Solution: ========= set id of the tag to `tag_15` and the for attribute of the label to `tag_15` to avoid the conflict with the category checkbox. opw-3759654 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156940
This update includes several important fixes and improvements across Odoo's core modules. Key changes address issues with contact widget crashes when handling missing data, improve the user experience in accounting workflows, fix kanban view functionality, and add support for new countries. These updates enhance system stability and usability for end users.
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 fix resolves crashes that occurred when users searched on outdated job listing pages. The system now automatically redirects users from old job URLs to the new ones while preserving their search parameters, ensuring a smooth experience without errors.
Original PR description
__Current behavior before commit:__ `/jobs` routes have been modified in [this commit][1]. Old ones are deprecated but are still working for backward compatibility. When searching on this page,…
__Current behavior before commit:__ `/jobs` routes have been modified in [this commit][1]. Old ones are deprecated but are still working for backward compatibility. When searching on this page, search params are now just added at the end of the URL (instead of being part of the path like before). If the URL of the page is a deprecated one, this can create a conflict with the previous way the params were handled and produce an error. __Description of the fix:__ Redirect the user to the new route any time he tries to reach the deprecated ones. Any parameters included in the old URL will be carried over to the new route to maintain expected behavior. If a parameter is provided both in the path and as a kwarg, the kwarg value will take precedence. __Steps to reproduce the issue on runbot:__ 1. Go to `/jobs/country/20` 2. Make a search using the search bar -> Crash opw-3781374 [1]: https://github.com/odoo/odoo/commit/54f246f9c75b8f1ebdc637c6000f3e4773d702d5 Forward-Port-Of: odoo/odoo#156918
This fix resolves an issue where Stripe payment information could cause errors when certain card data fields are missing or empty. The system now properly handles cases where card details aren't provided by Stripe, and also supports alternative payment methods used in Canada. This prevents system crashes when processing certain types of card transactions.
Original PR description
According to stripe documentation, the `card_present` attribute can be nullable, see: https://docs.stripe.com/api/charges/object#charge_object-payment_method_details-card_present https://docs.stripe.com/api/payment_methods/object#payment_method_object-card_present As a consequence, if it is not given, card_present values would be undefined which create a JS traceback when the `brand` attribute is get. It also looks like Canada can give the brand under a different key `interac_present`: https://docs.stripe.com/api/charges/object#charge_object-payment_method_details-interac_present If the `card_present` key is missing, we'll try to read it from there opw-3752751 Forward-Port-Of: odoo/odoo#156009 Forward-Port-Of: odoo/odoo#155702
This update corrects a translation mistake in the French localization module that was introduced in a previous commit. The fix ensures that French language text displays correctly for users in France, improving the accuracy of the system's French interface.
Original PR description
During this commit: https://github.com/odoo/odoo/commit/8bee46f117b1e6822429e8688f70cb27cc237bb4 We have translated the l10n_fr localisation, but we made a mistake on a line. This PR will correct the translation issue Task: 3792865 opw-3754691 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Documentation and clarification updates
VG&Co. has signed the Corporate Contributor License Agreement (CLA), which is now recorded in the repository. This legal agreement allows the company to contribute code to Odoo while protecting both the contributor and the project.
Original PR description
Corporate CLA Signature