Daily updates from Odoo
Navigate
Branch
Thursday, June 19, 2025
67 changes
35 changes
Enhancements to existing features
Stock move descriptions are now generated dynamically while still preserving manual edits when users customize them. Kit-related information is folded into the main picking description, reducing duplicated stored data and keeping stock documents more consistent across delivery, manufacturing, and localization workflows.
Original PR description
- Remove name field (stored) on stock.move, replace by reference field (computed) - Make description_picking field on stock.move computed (instead of stored), but allow manual edits to be persisted (with manual stored field + inverse) - Remove the kit field (description_bom_line) and move this information to the description_picking (computed)
The related spreadsheet, documents, and Studio tests were updated to reflect a broader availability of the “in” filter option. This helps ensure these business features remain reliable after the underlying domain selector behavior changed.
Original PR description
We adapt the tests in documents_spreadsheet, spreadsheet_edition and web_studio to the changes brought by https://github.com/odoo/odoo/pull/208592. Task ID: 4610804
Users can now drag unplanned tasks into the calendar to schedule them directly, without switching views or editing each task form. This streamlines planning work for project and field service teams on desktop.
Original PR description
Before this commit, it was not easily possible for the user to plan his existing tasks inside the calendar view, he was to go another view or add planned dates in the form view of his tasks. This commit adds the tasks to plan in desktop mode only to let the user to drag and drop his tasks unplanned to a calendar cell to directly plan them. task-4645814
Users can now choose project templates more easily from Gantt and related project workflows. This helps teams standardize how new projects and tasks are created across field service, helpdesk, timesheets, sales, rentals, and forecasting processes.
Original PR description
_* = project_helpdesk, timesheet_grid, sale_renting_project, project_forecast , helpdesk_timesheet, helpdesk_fsm Change related to community task-4700744
Account returns now open with a chatter panel to centralize conversations, attachments, status changes, API responses, and activity logs. This makes it easier for users to follow the history of a return in one place, though the chatter is not available on mobile.
Original PR description
Opens a chatter when clicking on an account return. Attachments are no longer accessible with a button but using the chatter attachments section. The goal of this feature is to record states changes, API responses, log of activities, ... This chatter isn't accessible in mobile. Co-authored-by: <leol@odoo.com> task-4809711
Mexican electronic invoicing now supports all CFDI tax object classifications instead of only a limited subset. This gives users more accurate control over how taxes are represented on invoices, bills, and related documents, helping improve compliance with CFDI 4.0 requirements.
Original PR description
Since the launch of CFDI 4.0 we have had the option to check a box and not have the taxes displayed on the CFDI. That allows to have control of objetoImp = 03. However, there are 8 values to cover and only 3 are managed. Also, the user has no control of it. task_id: 4365578
PDF financial reports now have a cleaner, more polished layout with the company logo in the header, better title and filter placement, and clearer table styling. This improves readability and gives exported reports a more professional appearance for sharing with stakeholders.
Original PR description
Improve the pdf design of reports by: - adding the logo in the header. - removing the gray background on the header. - moving the title to the right, with the filters underneath. - adding gray background to the table header, remove the border. - adding more space between the lines of the table. task-4546858
Customers can now pause eligible subscriptions directly from the online portal for up to one month within the current billing period. They can also resume early, which restarts billing from the current date and gives businesses a more flexible self-service subscription experience.
Original PR description
Customers can now pause their subscriptions from the portal if the subscription plan allows it. The pause duration is limited to one month and is only applicable for current invoice periods. A resume option is also provided, enabling customers to restart their subscriptions before the pause ends. Upon resumption, the next invoice date is set to the current date, and invoicing continues as usual. task:3414468
Billable projects now show a Rental Orders action in the project top bar and dashboard for authorized sales users. This makes it easier to find project-related rental orders and ensures new rental orders are automatically linked to the right project, while keeping them separate from standard sales orders.
Original PR description
This commit introduces a Rental Orders action in the project’s top bar task view and dashboard. - Displays rental orders linked to the current project. - Restrict visibility to billable projects and users with `group_sale_salesman` access rights. - Auto-assign the current project when creating a new rental order. - Exclude rental orders from the Sales Orders embedded view. task-4764598
Web Studio’s automated tests were adjusted to reflect that ID values are now required. This helps keep internal quality checks aligned with current behavior and reduces the risk of test failures during development.
Original PR description
Id becomes required, adapt test of web_studio
Address changes for partners no longer trigger a separate step to clear saved map coordinates. This simplifies the map functionality because partner locations are now refreshed automatically by the geolocation system when an address changes.
Original PR description
Before this commit: The partner coordinates were cleared when the address fields changed, using an onchange method. After this commit: This is no longer needed, as coordinates are now automatically recomputed in the `base_geolocalize` module when the address is updated. Task-4812621
External tax integrations now use the exact tax amounts returned by providers like Avalara instead of relying on Odoo to recalculate them. This improves accuracy for cases such as full or partial tax exemptions and simplifies the underlying tax flow, reducing the risk of mismatched invoice or sales order taxes.
Original PR description
For details, see the individual commits.
A rough diagram of code execution flow after the refactor (numbering on the edges is the call order, essentially left-to-right, top-to-bottom):
```mermaid
flowchart LR
X["_get_and_set_external_taxes_on_eligible_records (*account.external.tax.mixin*)"] -->|1| A
X -->|9| Y["_set_external_taxes *(account.external.tax.mixin, api.model)*"]
A["_get_external_taxes (*account.external.tax.mixin*)"] -->|2| B[_get_avatax_service_params]
A -->|3| C["_prepare_avatax_document_service_call (*api.model*)"]
C -->|4| D["_prepare_avatax_document_line_service_call (*api.model*)"]
A -->|5| E["*call external tax API*"]
A -->|6| F["_extract_tax_values_from_avatax_detail *(api.model)*"]
A -->|7| G["_process_external_taxes *(account.external.tax.mixin, api.model)*"]
A -->|8| H["*returns manual tax amounts*"]
```
task-4601840The barcode app now labels the button as "Print Product Labels" instead of "Print Barcodes." This makes the action clearer for users who are printing labels for products.
Original PR description
"Print Barcodes" => "Print Products Labels" task-3959326 Community PR: odoo/odoo#178236
The Enterprise web interface primary colors were adjusted to improve text readability and overall contrast. This should make key interface elements easier to read and provide a clearer visual experience for users.
Original PR description
As part of R&D design team training, primary colors were changed to offer better text readability and better contrast. Requires : - https://github.com/odoo/odoo/pull/214768 task-4875580
Sign template editors can now mark text fields as read-only, so predefined wording or automatically filled values cannot be changed by signers. This helps companies keep required language, formatting, and standardized content consistent during signing while still displaying the information clearly.
Original PR description
## Purpose Text fields sometimes need to follow a format that should not be changeable (due to the company language, user languages and other factors). We should provide the functionality of making text fields read-only in the Sign Templates to expand the options of the editor. task id: 4606205
Resolved issues and error corrections
This fix ensures SEPA Direct Debit payment setup is completed for companies that already existed before the module was installed. Businesses can now configure and use the provider reliably across all companies, avoiding unusable payment records caused by missing setup data.
Original PR description
Since https://github.com/odoo/odoo/commit/0d3228e10d04a01c87fbef1e0e78b37c462c9ea5, payment providers are automatically duplicated for newly created companies. However, if a provider module is…
Since https://github.com/odoo/odoo/commit/0d3228e10d04a01c87fbef1e0e78b37c462c9ea5, payment providers are automatically duplicated for newly created companies. However, if a provider module is installed after creating a new company it does not work. Steps to reproduce: - Create a new company without installing any payment provider. - Install `payment_sepa_direct_debit` module after the company is created. - You’ll notice that the `code` field is not set on the provider record copied to the new company, which makes the provider unusable. Issue: - Provider record is missing critical fields like `code` in newly created companies. - Without these fields, it’s impossible to configure or use the provider. Cause: - When the module is installed after company creation, the provider setup does not run for those companies, so the copied records are incomplete. Solution: - Add `post_init_hook` to copy the provider after installation. - This ensures all required fields like `code` are correctly set up in all companies. See Also: https://github.com/odoo/odoo/pull/213804 opw-4857980 affected version-master
The payroll system now shows the out-of-contract warning more accurately when reviewing payslips. This helps payroll teams avoid unnecessary confusion and better identify payslips that may need attention before processing.
Miscellaneous changes
Description ----------- Changes introduced: - Replaced `filtered` linear search with direct `search_fetch` using partner's id in the domain when computing `user_permission` in `_get_permission_without_token` function. This optimizes querying document access permissions. - Implemented batch processing for `_get_permission_without_token` to consolidate documents' access permissions into a single database query. Benchmark --------- `_compute_user_permission` for 1.4k documents for reques
Original PR description
Description ----------- Changes introduced: - Replaced `filtered` linear search with direct `search_fetch` using partner's id in the domain when computing `user_permission` in `_get_permission_without_token` function. This optimizes querying document access permissions. - Implemented batch processing for `_get_permission_without_token` to consolidate documents' access permissions into a single database query. Benchmark --------- `_compute_user_permission` for 1.4k documents for request `search_panel_select_range` (called when opening the Documents app) takes: | Before | After | Speed-up | |--------|-------|----------| | 6.86s | 52ms | 131.9x | Reference --------- task-4873406 Forward-Port-Of: odoo/enterprise#87737
Before this PR: - IRN number was also copied when a record was duplicated or while creating a debit/credit note for purchase document. - This caused the same IRN to appear on multiple records. After this PR: - Now, when a record is duplicated or a debit/credit note is created, the IRN number will be empty to prevent duplication. Task Id: 4854568 Forward-Port-Of: odoo/enterprise#87945 Forward-Port-Of: odoo/enterprise#87468
Original PR description
Before this PR: - IRN number was also copied when a record was duplicated or while creating a debit/credit note for purchase document. - This caused the same IRN to appear on multiple records. After this PR: - Now, when a record is duplicated or a debit/credit note is created, the IRN number will be empty to prevent duplication. Task Id: 4854568 Forward-Port-Of: odoo/enterprise#87945 Forward-Port-Of: odoo/enterprise#87468
The `_compute_show_method` relied on the context key `l10n_it_xml_export_monthly_tax_report_options` that may not be present during generic field tests (e.g. `model.new()`). This caused a Runbot failure in `test_computed_fields_without_dependencies`. This fix ensures the compute method exits safely if the required context is missing. [runbot-162081](https://runbot.odoo.com/odoo/error/162081) Forward-Port-Of: odoo/enterprise#87671 Forward-Port-Of: odoo/enterprise#87086
Original PR description
The `_compute_show_method` relied on the context key `l10n_it_xml_export_monthly_tax_report_options` that may not be present during generic field tests (e.g. `model.new()`). This caused a Runbot failure in `test_computed_fields_without_dependencies`. This fix ensures the compute method exits safely if the required context is missing. [runbot-162081](https://runbot.odoo.com/odoo/error/162081) Forward-Port-Of: odoo/enterprise#87671 Forward-Port-Of: odoo/enterprise#87086
Removing MISC journal from the dashboard of the Enterprise Invoicing App. Two cases need to be covered for it to be shown in the Enterprise Accounting App: 1) existing companies -> installing accountant : the show_on_dashboard field is set to True in the post_init of the accountant module. 2) accountant installed -> creating new companies : the show_on_dashboard field is set to True in the _post_load_data of the account chart template. task-4730184 Forward-Port-Of: odoo/enterprise#87
Original PR description
Removing MISC journal from the dashboard of the Enterprise Invoicing App. Two cases need to be covered for it to be shown in the Enterprise Accounting App: 1) existing companies -> installing accountant : the show_on_dashboard field is set to True in the post_init of the accountant module. 2) accountant installed -> creating new companies : the show_on_dashboard field is set to True in the _post_load_data of the account chart template. task-4730184 Forward-Port-Of: odoo/enterprise#87020 Forward-Port-Of: odoo/enterprise#83620
Sync zh_TW po files for easier testing of zh_HK support zh_hk po files were very old/mostly not translated => delete them
Original PR description
Sync zh_TW po files for easier testing of zh_HK support zh_hk po files were very old/mostly not translated => delete them
**Steps to reproduce:** 1. Install hr_payroll. 2. Create a salary rule (with a structure where country_id is null) and set `View on Payroll Reporting?` is checked for a custom field (x_l10n_xx_%). 3. Add the custom field to the payroll report's pivot view using Studio. **Issue:** - The pivot view fails to open, resulting in a traceback. ``` UncaughtPromiseError > OwlError Uncaught Promise > The following error occurred in onWillStart: "Cannot read properties of undefined (reading
Original PR description
**Steps to reproduce:** 1. Install hr_payroll. 2. Create a salary rule (with a structure where country_id is null) and set `View on Payroll Reporting?` is checked for a custom field (x_l10n_xx_%). 3.…
**Steps to reproduce:** 1. Install hr_payroll. 2. Create a salary rule (with a structure where country_id is null) and set `View on Payroll Reporting?` is checked for a custom field (x_l10n_xx_%). 3. Add the custom field to the payroll report's pivot view using Studio. **Issue:** - The pivot view fails to open, resulting in a traceback. ``` UncaughtPromiseError > OwlError Uncaught Promise > The following error occurred in onWillStart: "Cannot read properties of undefined (reading 'string')" ``` **Cause:** - Custom field that not start with `l10n_<country_code>` or `x_l10n_<country_code>` are removed, causing undefined fields in the pivot view. https://github.com/odoo/enterprise/blob/ccb5ed4779db4bdf6944f43eb2e4a7aa978b9272/hr_payroll/static/src/js/hr_payroll_report_pivot_model.js#L13-L15 **Solution:** - Allow to add custom fields created from salary rules without a country code to be used as custom measures in the pivot view. opw-4688376 Forward-Port-Of: odoo/enterprise#84881
We did not send an `ACK` after asking for blackbox status, leading in BlackBox sending it again. This lead to situations where we sent requests to the BlackBox, and received the status instead of the actual response. In addition, the repeated status responses were missing the leading `ACK`, resulting in our log: `sent 1 NACKS without receiving response, giving up.` More, if we sent a command too soon to the BlackBox (before it finished instanciating), we were receiving its `certified ref` in
Original PR description
We did not send an `ACK` after asking for blackbox status, leading in BlackBox sending it again. This lead to situations where we sent requests to the BlackBox, and received the status instead of the actual response. In addition, the repeated status responses were missing the leading `ACK`, resulting in our log: `sent 1 NACKS without receiving response, giving up.` More, if we sent a command too soon to the BlackBox (before it finished instanciating), we were receiving its `certified ref` instead of the actual response, due to the `_push_status` method called from the `run` method of the BlackBox Driver parent class. This `run` method is now overridden by the BlackBox driver Task: 4750435 Forward-Port-Of: odoo/enterprise#87659
Current Behavior: When validating a SEPA Direct Debit batch payment, Odoo automatically attempts to send a pre-notification email using the email template account_sepa_direct_debit.email_template_sdd_pre_notification. If this template is missing (e.g. deleted or unlinked), the process fails with a ValueError: External ID not found, and the batch cannot be validated. Expected Behavior: If the template is missing, no pre-notification email should be sent, but the batch validation shoul
Original PR description
Current Behavior: When validating a SEPA Direct Debit batch payment, Odoo automatically attempts to send a pre-notification email using the email template account_sepa_direct_debit.email_template_sdd_pre_notification. If this template is missing (e.g. deleted or unlinked), the process fails with a ValueError: External ID not found, and the batch cannot be validated. Expected Behavior: If the template is missing, no pre-notification email should be sent, but the batch validation should still proceed without error. The process must not raise a traceback or prevent validation. task-4815699 Forward-Port-Of: odoo/enterprise#86278
Since https://github.com/odoo/odoo/pull/205922, the highlighting system for settings search results was changed and although undesired tags are removed with https://github.com/odoo/odoo/pull/211832, there are still spacing issues that are addressed here. Forward-Port-Of: odoo/enterprise#86508
Original PR description
Since https://github.com/odoo/odoo/pull/205922, the highlighting system for settings search results was changed and although undesired tags are removed with https://github.com/odoo/odoo/pull/211832, there are still spacing issues that are addressed here. Forward-Port-Of: odoo/enterprise#86508
Steps: - Create an employee with marital status is married - Keep the spouse name empty - Try to export ird reports with a confirmed payslip Current behavior: - Error raised Expected behavior: - Should be able to export the report even spouse name is empty Forward-Port-Of: odoo/enterprise#87926 Forward-Port-Of: odoo/enterprise#86270
Original PR description
Steps: - Create an employee with marital status is married - Keep the spouse name empty - Try to export ird reports with a confirmed payslip Current behavior: - Error raised Expected behavior: - Should be able to export the report even spouse name is empty Forward-Port-Of: odoo/enterprise#87926 Forward-Port-Of: odoo/enterprise#86270
- Before this commit, when a POS order was created with an urban piper delivery method, the blackbox data was not saved to the database. - Now we explicitly save the bbox data to ensure this info is displayed on the receipt. task-id: 4781945 Forward-Port-Of: odoo/enterprise#87841
Original PR description
- Before this commit, when a POS order was created with an urban piper delivery method, the blackbox data was not saved to the database. - Now we explicitly save the bbox data to ensure this info is displayed on the receipt. task-id: 4781945 Forward-Port-Of: odoo/enterprise#87841
- Enabled editing of reconciled entries in mobile view on-click. - Foreign-currency values are now omitted from the mobile display. Task ID: 4749337 Forward-Port-Of: odoo/enterprise#84691
Original PR description
- Enabled editing of reconciled entries in mobile view on-click. - Foreign-currency values are now omitted from the mobile display. Task ID: 4749337 Forward-Port-Of: odoo/enterprise#84691
Currently, an error is produced when the payslip start date is not set, but the end date is provided. **Steps to reproduce:** - Install `hr_payroll` module(with demo). - Create new **Payslip** for employee **Anita Oliver**. - Clear both the start and end dates under the "Period" section. - Set only the end date. **Error:** `TypeError: '<' not supported between instances of 'bool' and 'datetime.date'` **Cause:** The `_compute_warning_message` method performs a comparison between `s
Original PR description
Currently, an error is produced when the payslip start date is not set, but the end date is provided. **Steps to reproduce:** - Install `hr_payroll` module(with demo). - Create new **Payslip** for…
Currently, an error is produced when the payslip start date is not set, but the end date is provided. **Steps to reproduce:** - Install `hr_payroll` module(with demo). - Create new **Payslip** for employee **Anita Oliver**. - Clear both the start and end dates under the "Period" section. - Set only the end date. **Error:** `TypeError: '<' not supported between instances of 'bool' and 'datetime.date'` **Cause:** The `_compute_warning_message` method performs a comparison between `slip.date_from` and `contract_id.date_start` without verifying if `date_from` is set. When `date_from` is `False`, the comparison `False < datetime.date(...)` - [1], raises a `TypeError`. [1] - https://github.com/odoo/enterprise/blob/a65314702b99df97c778d4f12f943191a19dafd1/hr_payroll/models/hr_payslip.py#L1029-L1031 This commit adds checks to ensure that start and end date is defined before performing date comparisons in warning message computation, preventing the error. Sentry - 6618275041 Forward-Port-Of: odoo/enterprise#86091
This commit fixes the alignment of the "back" button of the transfer view. It also removes the label from small "Transfer" buttons to remain consistent with the other buttons of the same type. task-4875960 | Before | After | |--------|--------| |  | ![Capture d’écran 2025-06-17 à 11 44 13](https://github.com/user-attachments/assets/bd6d475f-9bbe-48f4-adbb-68f37662
Original PR description
This commit fixes the alignment of the "back" button of the transfer view. It also removes the label from small "Transfer" buttons to remain consistent with the other buttons of the same type. task-4875960 | Before | After | |--------|--------| |  |  | |  |  | Forward-Port-Of: odoo/enterprise#87838
Commit 687e237 introduced auto-creation of reconciliation models based on user behavior, primarily analyzing the last 5 statement lines. However, it did not account for lines without a payment_ref. Since the payment_ref is used to build the matching key, we now restrict the logic to only fetch statement lines that have one. opw-4846098 Forward-Port-Of: odoo/enterprise#87832
Original PR description
Commit 687e237 introduced auto-creation of reconciliation models based on user behavior, primarily analyzing the last 5 statement lines. However, it did not account for lines without a payment_ref. Since the payment_ref is used to build the matching key, we now restrict the logic to only fetch statement lines that have one. opw-4846098 Forward-Port-Of: odoo/enterprise#87832
Forward-Port-Of: odoo/enterprise#83860
Original PR description
Forward-Port-Of: odoo/enterprise#83860
Before this commit, in Chrome, when the first item was placed on second page or later, clicking on "Click to start" to automatically scroll to the first sign item would stop earlier. As a result, the user would have to click again on the navigator to focus it and to fill the automatic value. task-id-4854650 Forward-Port-Of: odoo/enterprise#87748
Original PR description
Before this commit, in Chrome, when the first item was placed on second page or later, clicking on "Click to start" to automatically scroll to the first sign item would stop earlier. As a result, the user would have to click again on the navigator to focus it and to fill the automatic value. task-id-4854650 Forward-Port-Of: odoo/enterprise#87748
opw-4772870 opw-4664501 Forward-Port-Of: odoo/enterprise#87944 Forward-Port-Of: odoo/enterprise#86891
Original PR description
opw-4772870 opw-4664501 Forward-Port-Of: odoo/enterprise#87944 Forward-Port-Of: odoo/enterprise#86891
32 changes
Enhancements to existing features
The base module now shares common XML-RPC request and error handling in one helper instead of duplicating it across two entry points. This is an internal cleanup that should make future maintenance easier without changing user-facing behavior.
Original PR description
Extract shared XML-RPC logic into `_xmlrpc_common`, removing duplicate try/except. **Description of the issue/feature this PR addresses:** Addresses #214536 by centralizing the duplicated error handling code in the xmlrpc controllers. **Current behavior before PR:** Both `xmlrpc_1` and `xmlrpc_2` each contain an identical try/except around the call to `_xmlrpc`, leading to code duplication. **Desired behavior after PR is merged:** Introduce a private helper `_xmlrpc_common` that handles request checking and exception mapping for both routes, keeping the public methods minimal. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Archiving or moving folders with many large documents now avoids loading full file contents when they are not needed. This significantly reduces memory use and helps prevent failures for users managing heavy document collections.
Original PR description
## Issue When there are heavy (or a lot of) documents in a folder, the user cannot archive this folder as it would trigger a `MemoryError`. ### Analysis The `write` override could unnecessarily fetch…
## Issue
When there are heavy (or a lot of) documents in a folder, the user cannot archive this folder as it would trigger a `MemoryError`.
### Analysis
The `write` override could unnecessarily fetch the `datas` field (binary file content).
This happened because a condition checking `record.datas` was evaluated before checking if `datas` or `url` was actually present in the values being written. This could lead to slowness when e.g. archiving/unarchiving documents, as the ORM would fetch the binary content even when it was not needed.
## Solution
We leverage Python's boolean short-circuiting to ensure that this behavior is avoided.
### Benchmarks
Profiling peak memory consumption when moving 8 documents (66 Mb each) to the trash:
| Before | After | % |
|------------|------------| --- |
| 1.3 GiB | 96 Mb | - ~93% |
Query count when unlinking account.move (using Runbot data):
| Before | After |
|------------|------------|
| 66 | 72 |
(we may avoid these additional queries by prefetching the fields beforehand, let me know your thoughts)
```
[0.564 ms] query: SELECT "ir_attachment"."id", "ir_attachment"."name", "ir_attachment"."description", "ir_attachment"."res_model", "ir_attachment"."res_field", "ir_attachment"."res_id", "ir_attachment"."company_id", "ir_attachment"."type", "ir_attachment"."url", "ir_attachment"."public", "ir_attachment"."access_token", "ir_attachment"."store_fname", "ir_attachment"."file_size", "ir_attachment"."checksum", "ir_attachment"."mimetype", "ir_attachment"."create_uid", "ir_attachment"."create_date", "ir_attachment"."write_uid", "ir_attachment"."write_date", "ir_attachment"."original_id", "ir_attachment"."key", "ir_attachment"."website_id", "ir_attachment"."theme_template_id" FROM "ir_attachment" WHERE "ir_attachment"."id" IN (3398)
[0.713 ms] query: UPDATE "ir_attachment"
SET "res_id" = "__tmp"."res_id"::int4, "res_model" = "__tmp"."res_model"::VARCHAR, "write_date" = "__tmp"."write_date"::timestamp, "write_uid" = "__tmp"."write_uid"::int4
FROM (VALUES (3398, 117, 'documents.document', '2025-06-17T15:24:12.867699'::timestamp, 22)) AS "__tmp"("id", "res_id", "res_model", "write_date", "write_uid")
WHERE "ir_attachment"."id" = "__tmp"."id"
[0.305 ms] query: SELECT "ir_attachment"."id", "ir_attachment"."res_model", "ir_attachment"."res_id", "ir_attachment"."res_field", "ir_attachment"."public", "ir_attachment"."create_uid" FROM "ir_attachment" WHERE ("ir_attachment"."id" IN (3397))
[0.666 ms] query: SELECT "account_move"."id" FROM "account_move" WHERE ("account_move"."id" IN (255)) AND ("account_move"."company_id" IN (10)) ORDER BY "account_move"."date" DESC , "account_move"."name" DESC , "account_move"."invoice_date" DESC , "account_move"."id" DESC
[0.436 ms] query: SELECT "ir_attachment"."id", "ir_attachment"."name", "ir_attachment"."description", "ir_attachment"."res_model", "ir_attachment"."res_field", "ir_attachment"."res_id", "ir_attachment"."company_id", "ir_attachment"."type", "ir_attachment"."url", "ir_attachment"."public", "ir_attachment"."access_token", "ir_attachment"."store_fname", "ir_attachment"."file_size", "ir_attachment"."checksum", "ir_attachment"."mimetype", "ir_attachment"."create_uid", "ir_attachment"."create_date", "ir_attachment"."write_uid", "ir_attachment"."write_date", "ir_attachment"."original_id", "ir_attachment"."key", "ir_attachment"."website_id", "ir_attachment"."theme_template_id" FROM "ir_attachment" WHERE "ir_attachment"."id" IN (3397)
[0.436 ms] query: SELECT "documents_document"."id", "documents_document"."attachment_id", "documents_document"."active" FROM "documents_document" WHERE ("documents_document"."attachment_id" IN (3397)) ORDER BY "documents_document"."id" DESC
```
### References
opw-4552436
Memory flamegraphs available on the ticketThe Italian Libro Giornale PDF report has been made easier to read with clearer grouping, alternating background colors, and less repeated information. Journal entry numbers and dates now take up less space, making the report cleaner for review and record keeping.
Original PR description
Changes include: - Better background color alternation for each journal entry. - Journal Entry number is now shown only once, and in bold. - Moved the date into the same column as the Journal Entry number to save space. task-4844519
Resolved issues and error corrections
This update refreshes Odoo's spreadsheet component with fixes that reduce duplicate collaboration messages, improve performance during shared editing, and correct spreadsheet behaviors such as automatic resizing for array formulas. It also removes an invalid delete menu option, making spreadsheet use smoother and less confusing for users.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/55268816d [REL] 18.0.34 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/55268816d [REL] 18.0.34 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/093517d5c [FIX] collaborative: don't send duplicate messages [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/bbc9b0053 [PERF] collaborative: avoid useless transformations [Task: 4873461](https://www.odoo.com/odoo/2328/tasks/4873461) https://github.com/odoo/o-spreadsheet/commit/9216eee84 [FIX] sheet: autoresize didn't work for array formula [Task: 4822877](https://www.odoo.com/odoo/2328/tasks/4822877) https://github.com/odoo/o-spreadsheet/commit/8fac09350 [FIX] menus: hide invalid 'delete' option from edit menu [Task: 4854659](https://www.odoo.com/odoo/2328/tasks/4854659) Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Mehdi Rachico (mera) <mera@odoo.com> Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Fixes an issue where merging CRM leads could fail if older lead records had no priority value. This helps sales teams merge historical or incomplete lead data without interruptions.
Original PR description
The field priority is not required (even if it has a default) so it is possible to have False instead of a str.
Traceback occures when merging leads that contains historical data.
```
File "/home/odoo/src/odoo/saas-18.3/addons/crm/models/crm_lead.py", line 1501, in _merge_opportunity
merged_data = opportunities._merge_data(self._merge_get_fields())
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-18.3/addons/crm/models/crm_lead.py", line 1457, in _merge_data
data[field_name] = fcallable(field_name, self)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-18.3/addons/crm/models/crm_lead.py", line 1555, in <lambda>
'priority': lambda fname, leads: max(leads.mapped('priority')) if leads else False,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: '>' not supported between instances of 'str' and 'bool'
```Sales orders now block line items where negative prices and quantities would create inconsistent totals. Return-style lines with a negative quantity and normal positive price remain allowed, helping teams avoid billing errors while preserving valid return workflows.
Original PR description
This commit introduces validation to sale.order.line to prevent inconsistent behavior with negative prices and quantities: - A negative price unit with a positive quantity now raises a UserError. - A negative quantity with a negative price unit now raises a UserError. - A negative quantity with a positive price unit (e.g., for returns) remains valid. New test cases have been added to test_sale_order.py to cover these scenarios. Additionally, sale_order_line.py and test_sale_order.py have undergone extensive linting and formatting to comply with Odoo coding standards. 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 prevents the messaging interface from crashing in rare cases where a chat bubble appears but its related conversation is temporarily unavailable or deleted. Users should experience a smoother, more reliable chat experience while the system waits for data to load or recognizes that the conversation no longer exists.
Original PR description
There are some rare cases there's a chat bubble but no thread, e.g. when the thread is deleted and/or data hasn't be fetched (yet). These cases should assume no thread for a short time instead of following crash: ``` TypeError: Cannot read properties of undefined (reading 'importantCounter') ```
The attendance kiosk now shows the correct number of employees per department when used for a company other than the default one. This prevents misleading zero counts in multi-company setups and helps staff identify the right department during check-in.
Original PR description
**PROBLEM** When using the kiosk on a company that's not the default company, the employee count displayed for all department is 0. **STEP TO REPRODUCE** 1.install the attendance module. 2.select another company. 3.go to the kiosk (attendance/Kiosk Mode). 4.identify manually. 5.notice the department count is incorrectly displayed as 0. **CAUSE** When entering the kiosk, the user is disconnected from their session, the user in this context is the public_user who have only access to the default company. The _compute_total_employee filter employees based on the company we have access to, so any employee from the non-default company are not taken into account. **FIX** We set the allowed_company_ids to the correct company id in the request context. opw-4647574
This fix updates an internal HTML editor test so it waits properly for toolbar popovers before checking results. It reduces random test failures, helping keep development and release validation more dependable without changing user-facing behavior.
Original PR description
The expect assertion does not wait, and waiting one animation frame is not enough for popovers, like the toolbar, as explained in [1]. [1]: https://github.com/odoo/odoo/pull/211426/commits/54da715df84789f9a1acc0cfc91be41dcdbab140
This fixes an issue in the Mail composer where clicking Save or Cancel while editing a message could unexpectedly move the page. Users can now finish or discard edits without losing their place, making message updates feel smoother and less disruptive.
Original PR description
**Current behavior before PR:** Clicking "Cancel" or "Save" in the composer would unintentionally cause the page to scroll. **Desired behavior after PR is merged:** This default behavior is now prevented in `onClickCancelOrSaveEditText`. **task**-[4826935](https://www.odoo.com/odoo/my-tasks/4826935) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents an error when users edit quantities or open products on quotation lines in mobile view. It ensures related line-item information is available to widgets, so sales workflows continue without crashes.
Original PR description
**Note: issue discovered in saas-18.3** **Step to reproduce:** - In mobile view, create a quotation (version saas-18.3) - Trying to change the quantity or view the product a traceback will be…
**Note: issue discovered in saas-18.3**
**Step to reproduce:**
- In mobile view, create a quotation (version saas-18.3)
- Trying to change the quantity or view the product a traceback will be received
**Traceback**
```
Uncaught Promise > Cannot read properties of undefined (reading 'activeFields')
Occured on localhost:9000 on 2019-03-11 09:30:00 GMT
TypeError: Cannot read properties of undefined (reading 'activeFields')
at http://localhost:9000/web/assets/debug/web.assets_unit_tests_setup.js:82391:75
at async openRecord (http://localhost:9000/web/assets/debug/web.assets_unit_tests_setup.js:106172:18)
```
**Issue:**
fieldDependencies of widget are evaluated by `addFieldDependencies` function.
now if a field of type "x2many" is added as fieldDependencies, and field is not present in the form,
examples : [sol_product_many2one](https://github.com/odoo/odoo/blob/saas-18.3/addons/sale/static/src/js/sale_product_field.js#L409) and [qty_at_date_widget](https://github.com/odoo/odoo/blob/saas-18.3/addons/sale_stock/static/src/widgets/qty_at_date_widget.js#L119)
the `related` key is not added for such fields by `addFieldDependencies` function
https://github.com/odoo/odoo/blob/b092750d2a595ac6d4bb6402c0b78db5db6d4dce/addons/web/static/src/model/relational_model/utils.js#L52-L76
which is required, when opening the subview here
https://github.com/odoo/odoo/blob/b092750d2a595ac6d4bb6402c0b78db5db6d4dce/addons/web/static/src/model/relational_model/static_list.js#L227-L233
**opw-4858035**
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fixes an issue in Sales Projects where the project display used the wrong view type after a recent change. Users should again see the expected list-style view, reducing confusion when working with projects linked to sales.
Original PR description
opw-4865213 Caused-by: https://github.com/odoo/odoo/pull/212680
Video options such as autoplay and loop now appear as proper on/off switches in the editor, even when the website app is not installed. This keeps the video settings popup consistent and easier to use across setups.
Original PR description
Description of the issue this PR addresses: - The video settings popup has toggle options like autoplay and loop. These need styles from the website module to look like switches. Without that module, they show as checkboxes. Current behavior before PR: - When the website module is not installed, Toggle options look like checkboxes instead of switches. Desired behavior after PR is merged: - Basic switch styles are added directly in the html_editor module. Toggles now look correct even without the website module. task-4865400 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A faulty test setting was removed from the Italian e-invoicing website sale module. This helps the automated checkout tests run correctly, reducing false build failures without changing customer-facing behavior.
Original PR description
steps to reproduce : 1. Install l10n_it_edi_website_sale 2. run the test `test_public_user_codice_fiscale` remove the unknown key `test` from the tour build_error-223784
This change fixes a flaky internal test in the web module that could fail unpredictably. It simplifies the test setup, making automated checks more stable without changing customer-facing behavior.
Original PR description
This commit fixes a race condition in one of Hoot's internal tests. The fix simplifies the failing test since the previous manipulations were redundant and fragile. runbot [223471](https://runbot.odoo.com/odoo/runbot.build.error/223471) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents users from accidentally editing purchase and vendor bill matching records that are only meant for viewing. It avoids a save error in the Purchase Matching screen, making the vendor bill workflow more reliable.
Original PR description
Currently, an error is produced when attempting to edit fields in the **Purchase Line and Vendor Bill line matching view** model. **Steps to reproduce:** - Install the `purchase` module. - Open a Vendor Bill form and click the "Purchase Matching" button. - In the list view, change the **Vendor** field of any record. - Attempt to save. **Error:** ``` UndefinedTable relation "purchase_bill_line_match" does not exist LINE 1: UPDATE "purchase_bill_line_match" ``` Here, the `purchase.bill.line.match` model is defined with `_auto = False`, meaning it is a non-storable model, does not have a corresponding database table, and therefore cannot be updated directly. [1] - https://github.com/odoo/odoo/blob/5977da2c93d522ece984d2fa8a31624f4b612eca/addons/purchase/models/purchase_bill_line_match.py#L10-L12 This commit makes fields read-only in the model, avoiding unintended write attempts on a non-storable view model. Sentry-6629713332
This fix allows records that track HTML content history to be updated in batches without failing. It improves reliability for users and administrators when multiple versioned content records are changed at once.
Original PR description
Allow batch write on model using the `HtmlFieldHistory` mixin. task-4852381 task-4731389 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Appointment request emails now include configured CC contacts when manual confirmation is used. This ensures relevant contacts are informed as soon as a booking request is submitted, especially for resource-based appointments where otherwise no internal notification may be sent.
Original PR description
…ith manual confirmation **Steps to reproduce:** - Install Appointement app - Edit an appointement appointment type - Set manual confirmation for the appointement type - Add CC contact as well - Go…
…ith manual confirmation **Steps to reproduce:** - Install Appointement app - Edit an appointement appointment type - Set manual confirmation for the appointement type - Add CC contact as well - Go to the appointement website (/appointement) - Create an appointement and submit it - Nothing is sent to CC contact when the request is made **Issue:** Process was designed to only send notification mails to the CC contacts (`message_partner_ids`) when the request was approved or cancelled (`booked` or `cancelled` appointment_status) but not for `request` when using manual confirmation. This is also quite problematic if `Availability on` is set to resources, as no confirmation mail is sent to anyone in that case (when no CC is specified, there is no other user than the requester). The observed behavior is due to the new process used when making appointement, previously in 17.0 the state was directly set to 'booked' so the mail was directly created and no further mail was sent unless the user explicitly cancelled its appointment. **Fix:** Added 'request' to the filtering on 'appointment_status' when adding the mail templates. Adapted field description and mail templates for clarity. related: cc field description https://github.com/odoo/enterprise/commit/adf47c32ee190dbf98c266d0816c8d03c8cd3e4f appointment_status https://github.com/odoo/enterprise/commit/3c64aa6dcd191248f0806c0b84ffa416d455fde4 request template https://github.com/odoo/enterprise/commit/2316947a0251709f3e469fea996ffac8f4623d98 opw-4658521
The Documents app now automatically configures the Internal folder with the expected email alias, matching earlier behavior on SaaS. The Sign integration also avoids errors when that folder was removed before installation, making setup more reliable.
Original PR description
As in earlier versions, add an alias to the Internal folder so that it is configured out of the box on Saas. In sign, we make sure to not try and embed an action on the Internal folder if it was already deleted before the bridge is installed. Task-4690653
Australian payroll now calculates overtime on top of the fixed wage instead of diluting the hourly rate across extra hours. Casual loading is also prevented from applying to overtime, helping payslips reflect the intended pay rules more accurately.
Original PR description
Bug: 1. Worked overtime hours are included within the gross paid amount of a contract rather than being added on top. 2. Casual loading rate applies to Overtime hours. Steps to reproduce: 1. Create a payslip for an employee with a contract of Fixed wage of 2000 per week. 2. The created payslip is of correct amount with the standard 40-hours work week. 3. Add a work entry of type Overtime with duration of 4 hours. Recompute the worked days amounts. Current behavior: The total remains 2000 and the computed hourly rate becomes 2000/44=45.45 Expected behavior: The hourly rate should remain the same 50. The total should increase to be: fixed_wage + hourly_rate * overtime hours 2000 + 50 * 4 = 2200 Fix: 1. While computing the amounts for each worked days type, exclude hours of type Overtime from total hours when calculating the hourly rate. 2.The casual loading rate should not apply to Overtime work entry types. task-4617681
The duplicate transaction search in bank accounting now works even when the Starting Date field is left empty. If no date is entered, the system uses today's date instead, avoiding an error that could interrupt accounting users.
Original PR description
Currently, an error occurs when finding duplicate transactions in the bank. Steps to Reproduce: - Install the `accountant` module. - In `Accounting Dashboard`, click on `Bank`. - In Actions, click `Find Duplicate Transactions`. - Clear the `Starting Date` field and click save. `TypeError: unsupported operand type(s) for -: 'bool' and 'relativedelta'` This error occurs when the system attempts to find duplicate transactions without a Starting Date. When finding duplicate transactions, it tries to calculate the `prior_date` using `date_from - relativedelta(months=3)` [1]. However, since `date_from` is `False`, this raises an error. [1] https://github.com/odoo/enterprise/blob/acdba5ecf89ee8920f82e07e16fac2a0f9659b12/account_online_synchronization/models/account_journal.py#L314 This commit ensures that if the Starting Date is empty when finding duplicate transactions, it uses today’s date as the Starting Date. sentry-6653835511
Miscellaneous changes
Creating a post using default values in context was bypassing the karma check when adding link or image. This no-so-sexy solution just ensure that whatever the way the post is created (using or not default values in context), the check is properly executed. Task-4114387 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197325
Original PR description
Creating a post using default values in context was bypassing the karma check when adding link or image. This no-so-sexy solution just ensure that whatever the way the post is created (using or not default values in context), the check is properly executed. Task-4114387 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197325
Description of the issue/feature this PR addresses: Some Romanian translations in the chart of accounts contained typos or imprecise terminology. These inaccuracies could lead to confusion for users relying on the Romanian localization. Current behavior before PR: Several account descriptions in Romanian included spelling errors or used vague or non-standard accounting terms. Desired behavior after PR is merged: Account descriptions in Romanian are now corrected, clearer, and better ali
Original PR description
Description of the issue/feature this PR addresses: Some Romanian translations in the chart of accounts contained typos or imprecise terminology. These inaccuracies could lead to confusion for users relying on the Romanian localization. Current behavior before PR: Several account descriptions in Romanian included spelling errors or used vague or non-standard accounting terms. Desired behavior after PR is merged: Account descriptions in Romanian are now corrected, clearer, and better aligned with official terminology, improving usability and compliance with Romanian accounting norms. The updated translations are based on the official ANAF reference: [SAF-T RO Schema Definition Codes v4.1.6](https://static.anaf.ro/static/10/Anaf/Informatii_R/SAF_T_Ro_SchemaDefinitionCodes_v4_1_6_final_1712021.xlsx) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212477
Before this commit, when using discuss call, using some usb camera would lead to wrong camera settings: ``` aspectRatio: 1.7777777777777777 frameRate: 20, height: 360, resizeMode: "crop-and-scale", width: 640, ``` This happens because of the camera config constraints that are not well understood by some usb cameras, such as `max` for width and height. Another problem is that `frameRate` was set to 30 but a camera can stream 30.0003 frames per seconds which is slightly higher. Becaus
Original PR description
Before this commit, when using discuss call, using some usb camera would lead to wrong camera settings: ``` aspectRatio: 1.7777777777777777 frameRate: 20, height: 360, resizeMode: "crop-and-scale",…
Before this commit, when using discuss call, using some usb camera would lead to wrong camera settings: ``` aspectRatio: 1.7777777777777777 frameRate: 20, height: 360, resizeMode: "crop-and-scale", width: 640, ``` This happens because of the camera config constraints that are not well understood by some usb cameras, such as `max` for width and height. Another problem is that `frameRate` was set to 30 but a camera can stream 30.0003 frames per seconds which is slightly higher. Because of the 30 value, it forces camera to stream a much lower framerate. Also somehow the camera panics and crop the content when this is not wanted. This commit fixes the issue by simplifying constraints to only asking for explicit width. This is well understood by many cameras and it just works. Framerate is managed by camera and bandwidth constraints, aspect-ratio has no reason to be limited by constraints and instead the source decides and call view managed the layout like it does now. With the same usb camera that give the results before, with the new contraints this become: ``` aspectRatio: 1.7777777777777777 frameRate: 30.000030517578125 height: 720 resizeMode: "none" width: 1280 ``` Forward-Port-Of: odoo/odoo#214886
Before master, this bug is mostly hidden since no WebP files are used by default. However, an upcoming PR targeting master converts all website images to WebP (https://github.com/odoo/odoo/pull/168862), revealing warnings in the server logs due to `binary_to_image` crashing on WebP inputs. This patch avoids the crash by explicitly handling WebP files with `get_webp_size()`. Forward-Port-Of: odoo/odoo#214706
Original PR description
Before master, this bug is mostly hidden since no WebP files are used by default. However, an upcoming PR targeting master converts all website images to WebP (https://github.com/odoo/odoo/pull/168862), revealing warnings in the server logs due to `binary_to_image` crashing on WebP inputs. This patch avoids the crash by explicitly handling WebP files with `get_webp_size()`. Forward-Port-Of: odoo/odoo#214706
Follow up of 1c17cb5a27483bb41b1e5ed820bc771a7337ec6d. It is OK to write raw bytes in a Binary attachment=False field. The thing actually is: * Binary fields, accept raw bytes, store raw bytes in db. * Image fields, reject raw bytes, want base64, store base64 in db. When reading Image fields it is easy: always decode the base64. For Binary fields it is complicated, because some crazy people encode their binary fields in base64, and expect automatic base64 decoding when read. Crazy
Original PR description
Follow up of 1c17cb5a27483bb41b1e5ed820bc771a7337ec6d. It is OK to write raw bytes in a Binary attachment=False field. The thing actually is: * Binary fields, accept raw bytes, store raw bytes in db.…
Follow up of 1c17cb5a27483bb41b1e5ed820bc771a7337ec6d. It is OK to write raw bytes in a Binary attachment=False field. The thing actually is: * Binary fields, accept raw bytes, store raw bytes in db. * Image fields, reject raw bytes, want base64, store base64 in db. When reading Image fields it is easy: always decode the base64. For Binary fields it is complicated, because some crazy people encode their binary fields in base64, and expect automatic base64 decoding when read. Crazy! So *attempt* to decode the b64 and if the decoding fail just assume it was raw bytes from the begining. Those crazy people even use silly base64 libraries to encode their bytes, e.g. `base64.encodebytes` which is a Email MIME utility: it adds `\r\n` every 76th character because of the folding requirements in email headers. So those bytes are "technically" not base64 (as far as `validate=True` is concerned) but we still must decode them. CRAZY. I'm looking at you `base.language.export.data`. Forward-Port-Of: odoo/odoo#214758
When grouping by week/days in a pivot, some issues can be seen for dates which week is between two years (for instance 12/30/2024 is both part of the last week of 2024 and the first week of 2025). Currently, such a date is assigned to week 1 of 2024 in a spreadsheet pivot, which is false and also messes up the group by of the first week of 2024. Technically, it's an issue with the date formatting "WW/YYYY" because the two parts are decorellated. Following the ISO calendar rules, the year of
Original PR description
When grouping by week/days in a pivot, some issues can be seen for dates which week is between two years (for instance 12/30/2024 is both part of the last week of 2024 and the first week of 2025).…
When grouping by week/days in a pivot, some issues can be seen for dates which week is between two years (for instance 12/30/2024 is both part of the last week of 2024 and the first week of 2025). Currently, such a date is assigned to week 1 of 2024 in a spreadsheet pivot, which is false and also messes up the group by of the first week of 2024. Technically, it's an issue with the date formatting "WW/YYYY" because the two parts are decorellated. Following the ISO calendar rules, the year of the date is obviously 2024 but the week of 12/30/2024 is 1 only because we consider it part of 2025. Since both parts of the information are gathered independently, we end up with this misleading formatted value. Note: the bug was fixed following a refactoring of the date handling but we keep the tests to ensure that there are no future regressions. Task-4853825 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#213698 Forward-Port-Of: odoo/odoo#213302
This commit fixes the `test_postcommit` that fails in a non deterministic fashion. This test ensures bus notifications created in the post commit hook result in only one batch. To do so, the test listens on the connection with a selector. However, the loop condition is incorrect and exits after the first select timeout. As a result, if the test takes more than 5 seconds, it fails. This commit fixes the loop condition to continue until the stop event is set. runbot-116746,161035,223589,7747
Original PR description
This commit fixes the `test_postcommit` that fails in a non deterministic fashion. This test ensures bus notifications created in the post commit hook result in only one batch. To do so, the test listens on the connection with a selector. However, the loop condition is incorrect and exits after the first select timeout. As a result, if the test takes more than 5 seconds, it fails. This commit fixes the loop condition to continue until the stop event is set. runbot-116746,161035,223589,77470 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#214737
This commit fixes the `second tab still receives notifications after main pagehide` test. This test simulates the main tab being closed. As a result, the main tab unregister itself from the worker. Upon message reception, the worker would try to access client's specific data such as channels or debug mode which are supposed to be available. However, since the client was unregistered, an error occurred. runbot-75372 Description of the issue/feature this PR addresses: Current behavior bef
Original PR description
This commit fixes the `second tab still receives notifications after main pagehide` test. This test simulates the main tab being closed. As a result, the main tab unregister itself from the worker. Upon message reception, the worker would try to access client's specific data such as channels or debug mode which are supposed to be available. However, since the client was unregistered, an error occurred. runbot-75372 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#214729
Description of the issue/feature this PR addresses: The invoice date was printed as l10n_sa_confirmation_date on the report, causing confusion for users issuing backdated invoices. Additionally, the issue date was being converted to the partner's timezone, leading to inconsistencies. Current behavior before PR: The invoice date appears as l10n_sa_confirmation_date on the report. The issue date is affected by the partner's timezone. Desired behavior after PR is merged: The report will d
Original PR description
Description of the issue/feature this PR addresses: The invoice date was printed as l10n_sa_confirmation_date on the report, causing confusion for users issuing backdated invoices. Additionally, the issue date was being converted to the partner's timezone, leading to inconsistencies. Current behavior before PR: The invoice date appears as l10n_sa_confirmation_date on the report. The issue date is affected by the partner's timezone. Desired behavior after PR is merged: The report will display both the standard invoice date and l10n_sa_confirmation_date separately for clarity. The issue date will always be passed in SA timezone to the report to ensure consistency, regardless of the partner's country. task-4508551 Forward-Port-Of: odoo/odoo#211992 Forward-Port-Of: odoo/odoo#200888
Prior to this commit, when validating a Scrap Order for a product with insuficient quantity, a wizard was shown to confirm the order as you would end up with a negative quantity in your warehouse. However, the view did not properly displayed quant_ids which allows seeing the current quantity for this product on the current warehouse as this compute field was not triggered during the first onchange call. When confirming the popup, the quant_ids could barely be seen before closing. The ide
Original PR description
Prior to this commit, when validating a Scrap Order for a product with insuficient quantity, a wizard was shown to confirm the order as you would end up with a negative quantity in your warehouse. However, the view did not properly displayed quant_ids which allows seeing the current quantity for this product on the current warehouse as this compute field was not triggered during the first onchange call. When confirming the popup, the quant_ids could barely be seen before closing. The idea is to make so that quand_ids can be seen as expected before any confirmation/cancelation. Forward-Port-Of: odoo/odoo#211152
Since #82896 reconciling bank statement line that has a partner with company_id set to a branch company leads to removing the partner from the statement line when validating the reconciliation. Steps: - Create a branch company and select it. - Create a contact with company_id == the branch company. - Create and confirm an invoice with that contact as partner. - Go back to accounting dashboard, and open bank reconciliation widget. - Create a new transaction with the invoice amount and tha
Original PR description
Since #82896 reconciling bank statement line that has a partner with company_id set to a branch company leads to removing the partner from the statement line when validating the reconciliation. Steps: - Create a branch company and select it. - Create a contact with company_id == the branch company. - Create and confirm an invoice with that contact as partner. - Go back to accounting dashboard, and open bank reconciliation widget. - Create a new transaction with the invoice amount and that partner. - Select it, and select the invoice we created, and click on Validate. - Notice that the partner is not set (removed) from the transaction. Fix: Add another condition to check if the statement line company matches the partner company before trying to unset the partner if its company isn't a root company. opw-4809740 Forward-Port-Of: odoo/enterprise#87440