Daily updates from Odoo
Navigate
Branch
Thursday, July 25, 2024
50 changes
16 changes
Resolved issues and error corrections
Website maps now wait for address lookup to finish before choosing the map center. This prevents maps from opening in the wrong place when coordinates are not already available, improving visitor experience on location pages.
Original PR description
Before this commit, the map could be wrongly centered if the longitude and latitude were unknown and localized on the fly using the JavaScript Geocoder API, as we did not wait for the result. Now, the code is reorganized as an async function, and we await all the promises before computing the map options.
This fixes a web testing helper so it more accurately detects whether an element is attached to a document. It helps prevent incorrect test behavior in edge cases, improving reliability for Odoo's web interface quality checks.
Original PR description
This commit ensures that the `isInDOM` helper function in Hoot actually checks that the given target is connected to a document. The previous implementation was naïve and only relied on the presence of a parent element. This was incomplete as there are some cases where a node is connected to a document element without having a `parentNode`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
### Steps to reproduce: - Install the 'l10n_sa' module and switch to a Saudi company - In the Settings of Accounting, tick the option "Default Terms & Conditions" and select "Add a Note" - Write something in for the Terms & Conditions - In the Accounting app create a new invoice, confirm and preview - At the bottom of the preview, the Terms & Conditions are duplicated ### Cause: The report is trying to print the Arabic and English translation of the Term & Conditions, but only one of th
Original PR description
### Steps to reproduce: - Install the 'l10n_sa' module and switch to a Saudi company - In the Settings of Accounting, tick the option "Default Terms & Conditions" and select "Add a Note" - Write…
### Steps to reproduce: - Install the 'l10n_sa' module and switch to a Saudi company - In the Settings of Accounting, tick the option "Default Terms & Conditions" and select "Add a Note" - Write something in for the Terms & Conditions - In the Accounting app create a new invoice, confirm and preview - At the bottom of the preview, the Terms & Conditions are duplicated ### Cause: The report is trying to print the Arabic and English translation of the Term & Conditions, but only one of the two exists, so they appear duplicated. ### Solution: There is already a way to translate manually the Terms & Conditions (Have the 2 languages installed, and a button appear near the text). So the fix is simply to display only the Arabic language when there is only one translation. A problem is that if the only translation is the English one, it will be printed as if it was written from right to left. But there is no way to know exactly the language of the text, and we can suppose the base language will be Arabic in most cases. opw-4043175 Forward-Port-Of: odoo/odoo#172781
Before this commit, if a settings app doesn't have settings (for instance if a setting header is not selected), the no content helper was always shown. The issue with this, is that the settings page is not a multi-record view, it's a customize form view, the content helper, it should only be shown if a search is performed and that no setting is found. This commit, fix this, and allow the no content helper to appear only if a search is performed and no setting is found. opw-4016050 Forward
Original PR description
Before this commit, if a settings app doesn't have settings (for instance if a setting header is not selected), the no content helper was always shown. The issue with this, is that the settings page is not a multi-record view, it's a customize form view, the content helper, it should only be shown if a search is performed and that no setting is found. This commit, fix this, and allow the no content helper to appear only if a search is performed and no setting is found. opw-4016050 Forward-Port-Of: odoo/odoo#174172 Forward-Port-Of: odoo/odoo#174059
To replicate the issue: - Go to the partner page of the current company (Invoicing > Customers > Customers > Look for the company) - Change type from Company to Individual - Create and post an invoice - Click on Send & Print. Download the Facturae - NAME should appear in line 30, before AddressInSpain, but it doesn't Cause of the issue: The template values do not include a value for self_party_name, only for other_party_name. In the template, when partner_name is set, no value is passed
Original PR description
To replicate the issue: - Go to the partner page of the current company (Invoicing > Customers > Customers > Look for the company) - Change type from Company to Individual - Create and post an invoice - Click on Send & Print. Download the Facturae - NAME should appear in line 30, before AddressInSpain, but it doesn't Cause of the issue: The template values do not include a value for self_party_name, only for other_party_name. In the template, when partner_name is set, no value is passed for self_party. Fix: Instead of only extracting the partner name for partner (other_party), the code is used in a new function, which can be called for both partner and company (self_party). Then, self_party_name can be used as a value in the template. opw-4053023 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174266 Forward-Port-Of: odoo/odoo#173608
This commit fixes an issue where the property values were not reset after creating a property, setting its value, using the pager to access another record and changing the property's type. When going back to the initial record, the old value would still be there and it could trigger a traceback depending on the type change (e.g. from string to integer). The issue is fixed by using a record observer to trigger _saveInitialPropertiesValues on record id change in the properties field component.
Original PR description
This commit fixes an issue where the property values were not reset after creating a property, setting its value, using the pager to access another record and changing the property's type. When going back to the initial record, the old value would still be there and it could trigger a traceback depending on the type change (e.g. from string to integer). The issue is fixed by using a record observer to trigger _saveInitialPropertiesValues on record id change in the properties field component. This allows to keep coherent values inside the initialValues and to generate a new property name properly when the property's definition changes. In case of a change in the property's name, the value of the property for all other records using it will be properly reset to default. OPW-4015949 Forward-Port-Of: odoo/odoo#173505
Steps to reproduce: - Open Project - Go into any project in kanban view - Mark any task as done. - From the progress bar click on done section Issue: - You can see that the color is does not apply while grouping tasks using progress-bar. Cause: - Missing css-kanban-filter which supplies the color to be applied while grouping by progressbar. - Adding CSS-filter is not done because success-done i.e. color of done tasks is not from standard CSS library(I.e. Bootstrap). Solutio
Original PR description
Steps to reproduce: - Open Project - Go into any project in kanban view - Mark any task as done. - From the progress bar click on done section Issue: - You can see that the color is does not apply while grouping tasks using progress-bar. Cause: - Missing css-kanban-filter which supplies the color to be applied while grouping by progressbar. - Adding CSS-filter is not done because success-done i.e. color of done tasks is not from standard CSS library(I.e. Bootstrap). Solution: - Add the CSS filter for done stage name as success-done. task-3852596 Forward-Port-Of: odoo/odoo#163086
Current behavior before PR: I. Inserting text into an empty paragraph tag with a `br` does not remove the `br`. II. When pasting single or multiple block elements the start and end block would unwrap causing inconsistency while pasting. III. Unwrapping the firstChild and the lastChild when pasting empty blocks resulted in the addition of br's to the block. Desired behavior after PR is merged: I. Inserting text into an empty node with a `br` should result in the removal of that `br`
Original PR description
Current behavior before PR: I. Inserting text into an empty paragraph tag with a `br` does not remove the `br`. II. When pasting single or multiple block elements the start and end block would unwrap causing inconsistency while pasting. III. Unwrapping the firstChild and the lastChild when pasting empty blocks resulted in the addition of br's to the block. Desired behavior after PR is merged: I. Inserting text into an empty node with a `br` should result in the removal of that `br`. II. Make sure if the node to start or end with is the same node we want to paste into; unwrap it, otherwise split the node. III. Empty blocks are no longer unwrapped when pasting. IV. This PR also addresses issues with testcases that includes `p` tag without a `br`. task-3630662 Forward-Port-Of: odoo/odoo#173890 Forward-Port-Of: odoo/odoo#160345
Problem: Partner address is never display in the partner list and the search doesn't work with the address Steps to reproduce: - Install "point_of_sale" app - Start a shop session - Click on "Customer" - The address is not displayed for any partner Cause: The address field of a partner got lost during refactoring in v17.1 opw-4032931 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172386
Original PR description
Problem: Partner address is never display in the partner list and the search doesn't work with the address Steps to reproduce: - Install "point_of_sale" app - Start a shop session - Click on "Customer" - The address is not displayed for any partner Cause: The address field of a partner got lost during refactoring in v17.1 opw-4032931 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172386
### Issue: Generated invoices does not appear in the page 'Manage Attachments'. ### Steps to reproduce: - Activate the developer mode - In Accounting > Customers > Invoices create a new one - Confirm and click on Send & Print, an invoice is generated and can be seen in the attachment of the chatter - Click on the debug icon, then on 'Manage Attachments' - The attachment does not show up ### Cause: The domain used for the 'Manage Attachments' search does not contain restriction on re
Original PR description
### Issue:
Generated invoices does not appear in the page 'Manage Attachments'.
### Steps to reproduce:
- Activate the developer mode
- In Accounting > Customers > Invoices create a new one
- Confirm and click on Send & Print, an invoice is generated and can be seen in the attachment of the chatter
- Click on the debug icon, then on 'Manage Attachments'
- The attachment does not show up
### Cause:
The domain used for the 'Manage Attachments' search does not contain restriction on res_field and id. So a new condition is added: ('res_field', '=', False). The logic behind this functionality is explained in this commit: https://github.com/odoo/odoo/commit/1bb61c970ed63eabe3821d21f3ed6f99c4b16daa In the case of invoices res_field is equal to invoice_pdf_report_file, so the invoice does not appear.
### Solution:
Add a context to the search request to skip the res_field test. Thus showing all attachments.
opw-3997094
Forward-Port-Of: odoo/odoo#172722Steps: - Login as portal, and to to a task form, page sub-tasks. - Make Customer column visible. - Add a line and try to edit that field. Issue: You can't. But after saving, you can. Cause: The new record doesn't have a project (it will be given to it on save). Yet this PR odoo#111335 added the condition that it should be invisible if no project. The reason why it caused no issue in 16.3 (where it was merged) was that there was a default project in `child_ids`'s context. Solution
Original PR description
Steps: - Login as portal, and to to a task form, page sub-tasks. - Make Customer column visible. - Add a line and try to edit that field. Issue: You can't. But after saving, you can. Cause: The new record doesn't have a project (it will be given to it on save). Yet this PR odoo#111335 added the condition that it should be invisible if no project. The reason why it caused no issue in 16.3 (where it was merged) was that there was a default project in `child_ids`'s context. Solution: In this case, the condition is not needed. Subtasks always have a project : private tasks can't have subtasks and deleting project field on a non-private task's subtask will actually give it its parent project. So the solution is simple: remove the condition. task-3713729 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174323
Backport of commit 2b27e1bd8015a26694ba66e95f5d62f19508b6ed Forward-Port-Of: odoo/odoo#174367
Original PR description
Backport of commit 2b27e1bd8015a26694ba66e95f5d62f19508b6ed Forward-Port-Of: odoo/odoo#174367
Fixed printer and serial devices detection: both listing more devices than expected. Task: 3947355 Forward-Port-Of: odoo/odoo#174164
Original PR description
Fixed printer and serial devices detection: both listing more devices than expected. Task: 3947355 Forward-Port-Of: odoo/odoo#174164
Some aliases to save a lot of time to IoT Team: - odoo, - odoo_help, - odoo_logs, - write_mode, - read_mode, - install, - blackbox. Use `odoo_help` to have more information. Task: 3947538 Forward-Port-Of: odoo/odoo#174085
Original PR description
Some aliases to save a lot of time to IoT Team: - odoo, - odoo_help, - odoo_logs, - write_mode, - read_mode, - install, - blackbox. Use `odoo_help` to have more information. Task: 3947538 Forward-Port-Of: odoo/odoo#174085
Enterprise: https://github.com/odoo/enterprise/pull/67366
Original PR description
Enterprise: https://github.com/odoo/enterprise/pull/67366
Current Behavior: Computation of the field `pos_order_count` on model `loyalty.program` is slow when there is a large number of `pos.order.line` records with `reward_id` set on them. Cause of the issue: The list comprehension done here --> https://github.com/odoo/odoo/blob/27ff3e0f64f53caa62c3022bd3b7c41e29a8e721/addons/pos_loyalty/models/loyalty_program.py#L59 The complexity is `O(len(self) * ((len(read_group_res) * len(program_reward_ids)) + len(read_group_res<sum method>)))` which pe
Original PR description
Current Behavior: Computation of the field `pos_order_count` on model `loyalty.program` is slow when there is a large number of `pos.order.line` records with `reward_id` set on them. Cause of the…
Current Behavior: Computation of the field `pos_order_count` on model `loyalty.program` is slow when there is a large number of `pos.order.line` records with `reward_id` set on them. Cause of the issue: The list comprehension done here --> https://github.com/odoo/odoo/blob/27ff3e0f64f53caa62c3022bd3b7c41e29a8e721/addons/pos_loyalty/models/loyalty_program.py#L59 The complexity is `O(len(self) * ((len(read_group_res) * len(program_reward_ids)) + len(read_group_res<sum method>)))` which performs slowly if the `self` and `read_group_res` are large. Improvement: Delegate the computation to Postgres and assign the values obtained from the result. Benchmark: In method `_compute_pos_order_count` Number of `pos.order.line` records eligible in computation --> 17803 Where `self` is a a `loyalty.program` recordset len(self)| Before (in seconds) | After PR (in seconds) | |---------|--------|--------| |1000| 177.28 s | 6.43 s | |212| 29.73 s| 0.5 s | Improvement by about 98% on average opw-3903159 Forward-Port-Of: odoo/odoo#172394 Forward-Port-Of: odoo/odoo#167386
17 changes
Enhancements to existing features
Helpdesk reports now use average calculations for fields where totals were misleading. This makes reporting clearer and prevents unnecessary measures from appearing automatically in cohort views.
Original PR description
A lot of field that appear in reporting views use the "sum" aggregate method, where the "avg" method would make more sense. This PR changes the aggregate method where needed. This has the added benefit of them not being automatically added to cohort views. Task-3383332
The 1099 box field is now positioned below the payment method field on partner records. This keeps related payment and tax reporting information grouped together, making the form easier to review and maintain.
Original PR description
In this commit: https://github.com/odoo/odoo/pull/172479/commits/47312748f5ce87a921877c46f1136ec7a23e7190 We moved the field property_payment_method_id into the account module and we want it to be below the payment terms in the res_partner view. This commit will change the xpath so that the field box_1099_id is now below the payment method field. task: 4016652
The Accounting app menu has been streamlined by removing section-style menu entries. This makes navigation clearer and helps users find accounting tools with fewer intermediate menu layers.
Original PR description
This commit will remove the sections menu items in the accounting menu. task: 4061527
The Data Cleaning app now includes reporting for data storage, helping teams better understand and manage stored records. This can support cleaner databases and more informed decisions about storage usage.
Resolved issues and error corrections
This update adjusts the field service report setup after a related project field was removed from the burn chart. It helps ensure the burn chart view continues to load and display correctly for users.
Original PR description
Removed project field from burn chart so we have to updated corresponding XPath. task-3999664
This fix ensures loyalty program descriptions are always provided when needed, preventing validation errors during related workflows. It helps keep discount calculations reliable for loyalty programs and avoids interruptions for teams using helpdesk, sales, and loyalty features.
Original PR description
**In this commit:** - Description field is made required because it is used for all programs and exclusively used to compute value of discount product. **Affected Version:** master **opw**-4032798
Code cleanup and technical improvements
This update removes an outdated option from Odoo's automated guided tour tests and replaces it with a simpler way to identify pop-up windows. It keeps test behavior aligned with the newer tour API while reducing maintenance complexity across several business apps.
Original PR description
https://github.com/odoo/odoo/pull/174315
This update removes an outdated setting from an automated Timesheet Grid walkthrough used for testing and guidance. It keeps the module aligned with the current tour system and helps reduce future maintenance issues, with no expected change for everyday users.
Original PR description
From b2b2576691750c0444d8871f95b733bec07ae45d, consumeEvent in no longer used in interactive Tour. Then, it's removed from tour API. task~3974087 https://github.com/odoo/odoo/pull/174347 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
Description of the issue this commit addresses: We do not want the user to be able to create fiscal years on child companies. --- Desired behavior after this commit is merged: A new check in fiscal years raises an error when the user tries to create a fiscal year from a child company. --- no task-feedback Forward-Port-Of: odoo/enterprise#67285 Forward-Port-Of: odoo/enterprise#67121
Original PR description
Description of the issue this commit addresses: We do not want the user to be able to create fiscal years on child companies. --- Desired behavior after this commit is merged: A new check in fiscal years raises an error when the user tries to create a fiscal year from a child company. --- no task-feedback Forward-Port-Of: odoo/enterprise#67285 Forward-Port-Of: odoo/enterprise#67121
Steps: - Install helpdesk_timesheet - In Kanban View > Start the timer of a ticket Issue: - If we have a kanban card with an older date and we start and stop the timer, a new kanban entry will be made with today's date. But for the tickets , if we start a timer, the ticket_id is not set in the timer header with in the new ticket. Cause: - Due to the condition given in the `action_start_new_timesheet_timer`, there is no helpdesk_ticket_id mentioned in that function. Fix: - B
Original PR description
Steps: - Install helpdesk_timesheet - In Kanban View > Start the timer of a ticket Issue: - If we have a kanban card with an older date and we start and stop the timer, a new kanban entry will be made with today's date. But for the tickets , if we start a timer, the ticket_id is not set in the timer header with in the new ticket. Cause: - Due to the condition given in the `action_start_new_timesheet_timer`, there is no helpdesk_ticket_id mentioned in that function. Fix: - By extending the `_get_new_timesheet_timer_vals` to the helpdesk_timesheet module to gave helpdesk_ticket_id the issue will be solved. task-3970176 Forward-Port-Of: odoo/enterprise#67294 Forward-Port-Of: odoo/enterprise#64359
- 17.0 We reverted the commit https://github.com/odoo/enterprise/commit/a789702766df289f4abe993374583a69027ef572 because it was causing the issue of hiding days when the row name was too long in the timesheet grid view. ### Steps to reproduce: - Install the project and timesheet app. - Open the project app, create a project, and add a task to it. - Add a timesheet a week before the current date for the created task. - Now open the timesheet app in grid view. - The created project and
Original PR description
- 17.0 We reverted the commit https://github.com/odoo/enterprise/commit/a789702766df289f4abe993374583a69027ef572 because it was causing the issue of hiding days when the row name was too long in the timesheet grid view. ### Steps to reproduce: - Install the project and timesheet app. - Open the project app, create a project, and add a task to it. - Add a timesheet a week before the current date for the created task. - Now open the timesheet app in grid view. - The created project and task are in italic font. - The last letter of the project and task name is slightly cut. ### Issue: The last letter of the string is slightly cut in the timesheet grid view. ### Cause: The dedicated space allowed for normal text is not sufficient for the italic. So, the last letter was slightly cut. ### Solution: Provide an extra space to the italic string. task-3888277 Forward-Port-Of: odoo/enterprise#67238 Forward-Port-Of: odoo/enterprise#63786
Currently it is assumed that all assets we write on belong to the same company. (Any exceptions to this are probably rare in practice.) This commit ensures that writing on assets with different companies works correctly. (no task) Forward-Port-Of: odoo/enterprise#67262 Forward-Port-Of: odoo/enterprise#65795
Original PR description
Currently it is assumed that all assets we write on belong to the same company. (Any exceptions to this are probably rare in practice.) This commit ensures that writing on assets with different companies works correctly. (no task) Forward-Port-Of: odoo/enterprise#67262 Forward-Port-Of: odoo/enterprise#65795
In this PR: Hide the `Timesheet Init Amount` and `Timesheet unit Amount` fields from the pivot and graph views. task-3970176 Forward-Port-Of: odoo/enterprise#67310 Forward-Port-Of: odoo/enterprise#64649
Original PR description
In this PR: Hide the `Timesheet Init Amount` and `Timesheet unit Amount` fields from the pivot and graph views. task-3970176 Forward-Port-Of: odoo/enterprise#67310 Forward-Port-Of: odoo/enterprise#64649
When opening the shopfloor from a specific workcenter, workorder or production order, only the concerned workcenter should be shown. task-4060857 Forward-Port-Of: odoo/enterprise#66923
Original PR description
When opening the shopfloor from a specific workcenter, workorder or production order, only the concerned workcenter should be shown. task-4060857 Forward-Port-Of: odoo/enterprise#66923
Steps: Login as portal, and to to a task form, page sub-tasks. Make Customer column visible. Add a line and try to edit that field. Issue: You can't. But after saving, you can. Cause: The field is invisible if `allow_billable` and `is_fsm` are False. A child task inherits both from its parent, but this one hasn't been created yet. Solution: In this case, the condition is not needed. If we create the child and he has both fields to False, it means its parent too. Yet the `partner_
Original PR description
Steps: Login as portal, and to to a task form, page sub-tasks. Make Customer column visible. Add a line and try to edit that field. Issue: You can't. But after saving, you can. Cause: The field is invisible if `allow_billable` and `is_fsm` are False. A child task inherits both from its parent, but this one hasn't been created yet. Solution: In this case, the condition is not needed. If we create the child and he has both fields to False, it means its parent too. Yet the `partner_id` column is invisible if it is the case. So the solution is simple: remove the condition. related: https://github.com/odoo/odoo/pull/174323 task-3713729 Forward-Port-Of: odoo/enterprise#67252
This improves the changes made by 6f1f45e137bbd87498b7e3998fe013716c2e66bf, moving the creation of the `account.move` at the approval step of an expense report. Before 6f1f45e137bbd87498b7e3998fe013716c2e66bf change: The `hr_payroll_expense` flow worked by relying on the fact that we created the expense sheet move at the very last moment, allowing to set the correct account to its payment term line, to reconcile with the payslip move easily. Before this change: In 6f1f45e137bbd87498b7e39
Original PR description
This improves the changes made by 6f1f45e137bbd87498b7e3998fe013716c2e66bf, moving the creation of the `account.move` at the approval step of an expense report. Before…
This improves the changes made by 6f1f45e137bbd87498b7e3998fe013716c2e66bf, moving the creation of the `account.move` at the approval step of an expense report. Before 6f1f45e137bbd87498b7e3998fe013716c2e66bf change: The `hr_payroll_expense` flow worked by relying on the fact that we created the expense sheet move at the very last moment, allowing to set the correct account to its payment term line, to reconcile with the payslip move easily. Before this change: In 6f1f45e137bbd87498b7e3998fe013716c2e66bf, since approving the report creates draft `account.move`s & `account.payment`s. This makes it more difficult to reconcile the two moves. A workaround was found in deleting the draft entry of the expense sheet when flagging it to be reimbursed through a payslip. After this change: This removes that workaround and allows a proper reconciliation of the two `account.move`s by using the draft entry `matching_number` mechanic. There are several improvements: - Avoid deleting a move, thus allowing it to be edited - Automatically reconcile, no matter if the accounts do not match, a misc entry is automatically generated if needed - Manual fallback, if the amounts of the two `account.move`s do not match, we keep the temporary `matching_number` set on the lines to help the accountant manually reconcile. We cannot do it automatically in this case as it requires user input (selecting an account for the write-off entry) task-id: 3955524 Forward-Port-Of: odoo/enterprise#64256
Before this commit, some Markup were missing in some post message which resulted in some html to be displayed in the chatter. task: 4041892 Community: https://github.com/odoo/odoo/pull/173375 Forward-Port-Of: odoo/enterprise#67255 Forward-Port-Of: odoo/enterprise#66767
Original PR description
Before this commit, some Markup were missing in some post message which resulted in some html to be displayed in the chatter. task: 4041892 Community: https://github.com/odoo/odoo/pull/173375 Forward-Port-Of: odoo/enterprise#67255 Forward-Port-Of: odoo/enterprise#66767
17 changes
New functionality added to Odoo
This update adds Balance Sheet and Profit & Loss reports specifically designed for Cyprus businesses, enabling them to generate compliant financial statements. Additionally, a fix ensures that VAT accounts are properly included in the Balance Sheet when using the EU OSS module, preventing reporting discrepancies.
Original PR description
This is a backport of #54620 and #59137
Enhancements to existing features
A warning banner now appears on tax reports when multiple companies are selected that have different tax IDs. This helps users identify potential reporting issues and ensures they're aware when companies with mismatched tax identifiers are included in the same report.
Original PR description
When having multiple companies selected and that their tax id are not the same, then we put a banner on top of the tax report to warn the user that the companies selected don't have the same tax id. task: 3909005
The bank reconciliation interface has been improved to display more consistent information across list and kanban views, including reference numbers, bank accounts, and currency details. Users can now view reconciliation details even after transactions are validated, and settings remain accessible for completed reconciliations, making the interface more user-friendly and informative.
Original PR description
This commit aims to: - make more coherent information displayed in the list view and the kanban view of the bank reconciliation widget. To do so we now display `ref`, `bank_account` `foreign_currency` and `amount_currency` within the "Manual Operations" tab. - display information even after the statement line is reconciled. To do so we made the "Manual Operations" tab visible even after validation, with its information in readonly. - make the cog menu available even if the transaction if validated. task-3996739
This update adds specialized financial reports for associations using the SYSCOHADA accounting standard. The system now distinguishes between reports for companies and associations, ensuring each organization type sees only the relevant financial statements. This improvement provides better compliance and clearer reporting for non-profit organizations operating under SYSCOHADA standards.
Original PR description
Adding another report for SYSCEBNL. We need to provide a way to add an availability for children of a COA, so the reports is only available for Associations (and not for Companies).
Resolved issues and error corrections
This fix resolves a system error that occurred when trying to enable Batch Transfers in Inventory settings on databases using Mexican EDI features. The issue was caused by a missing field reference that prevented the feature from being properly installed. Users can now successfully enable Batch Transfers without encountering errors.
Original PR description
When clicking on Batch Transfers in the settings to install stock_picking_batch on a database having l10n_mx_edi_stock_30 installed a traceback is raised due to the field l10n_mx_edi_is_delivery_guide_needed which is missing as it is removed in stock_picking_batch. Steps to reproduce: - Install l10n_mx_edi_stock_30 - In Inventory -> Configuration -> Settings - Check 'Batch Transfers', and Save A ParseError traceback appears. This commits aims to solve the issue by adding the field before its parent element is removed from the arch. Forward-Port-Of: odoo/enterprise#66798
Fixed an issue where sample values and button URLs in the WhatsApp Composer were not updating when users changed the WhatsApp template. Previously, the composer would display sample values from the initially selected template instead of the newly chosen one. Now, all sample values and dynamic URLs refresh automatically based on the selected template.
Original PR description
### Before this PR In WhatsApp Composer, the Sample Values do not update when changing the WhatsApp Template. Instead, it display the sample values from the initially selected template. This issue also occurs with the Button URL as well. ### After this PR The Sample Values for Free Text Fields and Button Dynamic URL will now update based on the selected WhatsApp Template. Task-3996935
This fix corrects a bug in the barcode scanning application where splitting a transfer line would incorrectly reset the source location to the warehouse default instead of preserving the original sublocation. When warehouse staff scan products from different shelf locations during internal transfers, the system now correctly maintains the original source location for the remaining quantity after a split occurs.
Original PR description
How to reproduce: ================= - Enable "Storage Locations"; - Create a product with a barcode and add some qty in a sublocation (e.g.: 10 products in Shelf 1); - Create an internal transfer from WH/Stock to WH/Stock for this product for at least 2 qty; - Confirm the internal transfer and open it in the Barcode app; - You can see you have one line, from WH/Stock/Shelf 1 to WH/Stock (if we follow previous example); - Scan one time the product, then scan another location (eg.: shelf2), the line will be split. => Issue here: the line for the remaining quantity has WH/Stock as source location instead of Shelf 1. Expected behavior: ================== The source location of the split line doesn't change. Explanation: ============ When a line is split, a new line is created for the remaining quantity. But the issue is, when a new line is created, it uses the picking's source location (or the previous scanned source) as the default location. OPW-4016136
This fix resolves an issue where appointment bookings in multi-company and multi-website environments were using the wrong company context, causing confirmation emails to be sent from the incorrect company. The system now correctly uses the company associated with the website where the appointment was booked, ensuring proper email delivery and company-specific settings are applied.
Original PR description
Before, in a multi company and mutli website setup, booking an appointment used the companies on the organizer for the context. This was leading to issue for appointment type in Website 2 tied to Company 2. Indeed the mails for the booking were sent with the context of Company 1 (value based on the allowed_company_ids of the user). Now, when website_appointment is installed, if a website is linked to the actual request we use the company tied to it. This ensure that we always use the correct company of the website for the creation of the event. We target 17.0 to avoid a behavior change in older stable as the multi website was officially supported for appointment type in that version. Could be backported if really necessary. task-3977787
The Mexican EDI stock module (l10n_mx_edi_stock_30) was failing to install on systems with large numbers of stock picking records due to excessive memory usage. This fix optimizes the installation process by manually creating database fields instead of performing automatic computations, allowing the module to install successfully even with large datasets.
Original PR description
Installation of l10n_mx_edi_stock_30 module can fail due to memory limit Having a large number of "stock.picking" records causes this due to the computations of the initial values of fields. Solving this requires creating the field columns and assigning the values manually, by overriding the _auto_init method. This allows us to skip the computations, to avoid the memory limit. opw-3846355 Forward-Port-Of: odoo/enterprise#60948
This update removes repair operation types from the list of picking types that can be selected when setting up quality control points. This prevents user confusion since quality checks cannot be created for repair operations, making the interface clearer and more intuitive.
Original PR description
Description of the issue/feature this PR addresses: 1 - Create a quality.point and add a repair operation type in the 'picking_type_ids' field 2 - Create a repair picking Current behavior before PR: No QC is created. This is expected because of https://github.com/odoo/enterprise/pull/59509 - only available since 17.3 Desired behavior after PR is merged: Exclude “repair” operation types from the domain of the “picking_type_ids” field to avoid confusing the user. opw-4052819
Fixed a display issue in the shop floor interface where the 'no content' message was incorrectly covering the entire screen, including the employee panel. The message now only appears for disabled workorders and is hidden on smaller screens, improving the overall user experience and screen real estate usage.
Original PR description
Before this commit, the 'no content' message was showing in the entire display, taking the employee panel account. Now, it is fixed, the message just stay at the disabled workorders, and when the screen is less than md, the message is hidded. Previous PR: https://github.com/odoo/enterprise/pull/62997 ### Before  ### After  task: 3794286
When a printer is removed from an IoT device, users previously saw a confusing error message. This fix now detects the missing printer on the server side and automatically clears the saved printer preference, allowing users to select a new printer on their next print attempt instead of encountering an error.
Original PR description
Before this commit: Having a printer P saved in the browser cache as the printer for a report R. If the printer P is removed from the IoT device, a pop-up error will raise when R tried to be printed with an unclear "iot.device(X) is missing". After this commit: The missing device is detected on the server side, and the cache is automatically cleaned for this report so that on the next attempt, the printer choice pop-up appear. Also took the opportunity to clean the JS code on the modified functions :) opw-3965623 opw-4017201
This fix ensures that all employees see consistent weekend highlighting in the Time Off calendar view, regardless of whether they have an active contract. Previously, employees without contracts or with contracts starting after certain dates would not display the grey weekend cells. Now the system properly falls back to company working hours to display the correct schedule information for all employees.
Original PR description
### Steps to reproduce: - Install hr_holidays_contract_gantt module - Create two employees one with a contract and another without - Create a time off for each employee - Check Time Off -> Overview ### Current behavior before PR: The employee who has a contract will have grey cells on weekend days that are coming after his contract start date but the ones before will be white. The employee who has no contract won't have any grey cells neither for his off days nor the weekend days. ### Desired behavior after PR is merged: Both employees should show the grey cells in the gantt view whether they have contract or not because if so we fallback on the employee working hours and then company's working hours 'According to the PO' opw-3961873
Fixed an issue where installing HR payroll modules would fail if certain accounting codes had been customized. The system now logs a warning instead of blocking installation, allowing users to proceed even when expected accounts are missing. This improves the flexibility of the payroll setup process.
Original PR description
Problem --------- Currently, if you install l10n_xx and update some specific account codes (depending on the localization) and then try to install the corresponding l10n_xx_hr_payroll_account hr module, you are struck with an error that cancels the installation as some accounts are missing. 1. Install l10n_ae for example 2. Switch to AE company 3. Update the account with code 201002 to 701002 4. Install l10n_ae_hr_payroll_account -> Error occurs during the installation Objective --------- Be able to install the module even when the account is missing. Solution --------- Log a warning instead of raising an error. opw-3961798
This fix corrects a display problem in the Chilean EDI module where HTML code was appearing as plain text in message conversations instead of being properly formatted. The issue was caused by missing markup formatting in post messages, which has now been resolved to ensure messages display correctly.
Original PR description
Before this commit, some Markup were missing in some post message which resulted in some html to be displayed in the chatter. task: 4041892 Community: https://github.com/odoo/odoo/pull/173375 Forward-Port-Of: odoo/enterprise#67255 Forward-Port-Of: odoo/enterprise#66767
Planning users were unable to view published shifts when draft shifts existed at the same time due to missing access permissions. This fix grants planning users the necessary access to draft shifts so they can properly view and manage shift conflicts without encountering errors.
Original PR description
We are facing an access error when the planning user tries to access the conflict shift because we have not given the planning user access to the draft shift. Steps to reproduce: - Install the planning app - Go to planning - Create two shifts at the same time (one published and the other in draft) - Create a new planning user - Log in as the planning user - Open the published shift task-3823274
This update significantly improves the speed of loading call activities in the VoIP system. The system was processing activities inefficiently by repeating the same data lookups for each individual activity. We've optimized this to process all activities together in one batch, reducing processing time by nearly 85% (from 581 seconds to 84 seconds for typical usage).
Original PR description
We notice that get_today_call_activities is a very frequent call that spend a lot of time runing sql queries. during 1h30 it was called 20515 times for an average of 719ms of sql times on odoo.com database. It was cause by _format_call_activities which can be called with many hundreds of activities before this commit for each activity _mail_get_partners and mail_partner_format were called once per activity. It take 581s for all the internal user of odoo.com database after this commit the method _mail_get_partners and mail_partner_format are called for an entire batch as it's intended. The same computation for internal user takes now 84s