Thursday, May 22, 2025
12 changes · saas-17.4
Resolved issues and error corrections
This update reverses a previous change related to closing a pop-up window before leaving a project task form. It helps restore the intended behavior in the Project app and reduces the risk of users being blocked or interrupted when navigating task records.
A timing issue in the automated sales project setup flow was addressed so the form is saved only after the popup closes. This reduces intermittent failures during validation and helps keep the sales-to-project workflow reliable.
Original PR description
Before this commit, the `task_create_sol_tour` could fail before the step did not wait enough the modal be closed before saving the form and so the form view could not be saved before going in the project app. This commit adds a step to make sure the modal is closed and does the step to save the form view when we check everything in the form view to make sure the form view will be saved before leaving the view. runbot-77457
Belgian payroll now consistently reflects the updated maximum public transport allowance of 43 euros instead of 34 euros. This keeps the contract salary guidance and related tests aligned with the current allowance rule, reducing the risk of incorrect expectations during payroll setup.
Original PR description
since this commit https://github.com/odoo/enterprise/commit/03c60aed528998456a858a9b64e6b3ff087af125 we change the maximum allowance from 34 to 43 euros. This should also show up in the function description and a test.
Miscellaneous changes
**Issue:** when defining the form for kanban view, required attribute is not added making it true by default **steps to reproduce:** 1. install timesheets app 2. from projects app, open a task with timesheet in mobile view 3. click on `Add` button present in timesheet page 4. try to save the timesheet without 'Description' observation: Form not saved with notification "invalid field: Description" **solution:** Add relevant `required` and `readonly` property to the field this ma
Original PR description
**Issue:** when defining the form for kanban view, required attribute is not added making it true by default **steps to reproduce:** 1. install timesheets app 2. from projects app, open a task with timesheet in mobile view 3. click on `Add` button present in timesheet page 4. try to save the timesheet without 'Description' observation: Form not saved with notification "invalid field: Description" **solution:** Add relevant `required` and `readonly` property to the field this makes the behavior same across each view [see list view](https://github.com/odoo/odoo/blob/17.0/addons/hr_timesheet/views/project_task_views.xml#L41-L54) note: 1. techincal name of Description field is 'name' 2. `readonly` attribute is added to make the behavior same across each view opw-4725348 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr ; Forward-Port-Of: odoo/odoo#209630
This **PR** introduces manual input for lines 01, 04, 10, and 25 in the mod.111 report. The previous automatic calculation based on tax tags was unreliable and could produce inaccurate values, so manual entry ensures the data correctly reflects actual figures. **task**-4797773 Forward-Port-Of: odoo/odoo#210279
Original PR description
This **PR** introduces manual input for lines 01, 04, 10, and 25 in the mod.111 report. The previous automatic calculation based on tax tags was unreliable and could produce inaccurate values, so manual entry ensures the data correctly reflects actual figures. **task**-4797773 Forward-Port-Of: odoo/odoo#210279
- Fixes the error coming from using discounts in invoices: the node `AllowanceChargeReasonCode` was added while not accepted by the Turkish implementation, and the amounts might not respect the asked format in some cases. - Fixes the error coming from invoices using a different currency than the company one (TRY). Although the documentation says the node `PricingExchangeRate` is only needed "If the prices of goods or services on the invoice are shown in a currency other than the 'Docum
Original PR description
- Fixes the error coming from using discounts in invoices: the node `AllowanceChargeReasonCode` was added while not accepted by the Turkish implementation, and the amounts might not respect the asked format in some cases. - Fixes the error coming from invoices using a different currency than the company one (TRY). Although the documentation says the node `PricingExchangeRate` is only needed "If the prices of goods or services on the invoice are shown in a currency other than the 'Document Currency", and our file did indeed use only one currency at a time (either all TRY or all USD amounts, e.g.), the server was still refusing our file. - Limits the decimal precision to 2 for most amoutns, as requested by the nilvera format. - Use uppercase on invoice names when putting them in the xml. task-4356940 Forward-Port-Of: odoo/odoo#205749
Currently because of the changes in ca35adf7412b132e37c22d09 both the test `test_increase_available_quantity_3` and `test_decrease_available_quantity_3` are always skipped, even with demo data. That's because `self.stock_location` points to a new location created in `setUpClass`. So no demo data quant can have this location_id as it cannot be referenced from a demo data file. However, "stock.stock_location_stock" is actually created in a data file, `stock_data.xml`. So we can revert back to u
Original PR description
Currently because of the changes in ca35adf7412b132e37c22d09 both the test `test_increase_available_quantity_3` and `test_decrease_available_quantity_3` are always skipped, even with demo data. That's because `self.stock_location` points to a new location created in `setUpClass`. So no demo data quant can have this location_id as it cannot be referenced from a demo data file. However, "stock.stock_location_stock" is actually created in a data file, `stock_data.xml`. So we can revert back to using `env.ref` instead of creating a new location. With that both tests are properly executed when demo data are installed while they are skipped without demo data. We're also creating the quants in case they are not found in the database so we ensure the test is always run. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#204682
Steps to reproduce: - Have a single currency active (no base.group_multi_currency) - Create a journal entry with lines: 1. Debit 10 | Credit 0 2. Debit 0 | Credit 10 - Save (note: line 2 `amount_currency` will be -10) - Modify the journal entry lines 2. (edit) Debit 10 | Credit 0 3. (new) Debit 0 | Credit 20 - Save Issue: Validation error will block the action psycopg2.errors.CheckViolation: new row for relation "account_move_line" violates check constraint "account_mov
Original PR description
Steps to reproduce: - Have a single currency active (no base.group_multi_currency) - Create a journal entry with lines: 1. Debit 10 | Credit 0 2. Debit 0 | Credit 10 - Save (note: line 2 `amount_currency` will be -10) - Modify the journal entry lines 2. (edit) Debit 10 | Credit 0 3. (new) Debit 0 | Credit 20 - Save Issue: Validation error will block the action psycopg2.errors.CheckViolation: new row for relation "account_move_line" violates check constraint "account_move_line_check_amount_currency_balance_sign" It occurs because, as we don't have `amount_currency` in the view, for line 2 the write operation will only store the updated values of `debit`,`credit`,`balance`, leaving the old amount of `amount_currency`. This creates an inconsistency as: - old `amount_currency` sign is negative - new `balance` sign is positive opw-4430334 Forward-Port-Of: odoo/odoo#202613 Forward-Port-Of: odoo/odoo#200566
In https://github.com/odoo/odoo/commit/6d2bfc85bc0e387fbf4d3a64eb15b18ec59e9b47 we removed an explicit flush performed right after move creation. Because of this change, when fetching data for the sie import we might not see all the relevant lines. We need to ensure to flush any data left in cache before making a SQL query no opw Forward-Port-Of: odoo/enterprise#82292
Original PR description
In https://github.com/odoo/odoo/commit/6d2bfc85bc0e387fbf4d3a64eb15b18ec59e9b47 we removed an explicit flush performed right after move creation. Because of this change, when fetching data for the sie import we might not see all the relevant lines. We need to ensure to flush any data left in cache before making a SQL query no opw Forward-Port-Of: odoo/enterprise#82292
Backport of https://github.com/odoo/enterprise/pull/70091/commits/bf9351317b08abe65b5d12f0a1e51144a6eafcf0 Forward-Port-Of: odoo/enterprise#76505
Original PR description
Backport of https://github.com/odoo/enterprise/pull/70091/commits/bf9351317b08abe65b5d12f0a1e51144a6eafcf0 Forward-Port-Of: odoo/enterprise#76505
This commit fixes an issue with the Facebook app and the management of pages. For Facebook to identify the user as able to manage a page, we need to provide another permission to the scope. The permission `business_management` is needed for the API to understand that the user is able to manage its pages. Thus we are adding it to the scope but as an optional permission. Some users may not have this permission set up for their own applications, thus we are adding the system parameter `social.
Original PR description
This commit fixes an issue with the Facebook app and the management of pages. For Facebook to identify the user as able to manage a page, we need to provide another permission to the scope. The permission `business_management` is needed for the API to understand that the user is able to manage its pages. Thus we are adding it to the scope but as an optional permission. Some users may not have this permission set up for their own applications, thus we are adding the system parameter `social.facebook_no_business_management`. This parameter blocks the addition of the permission to the scope if set to any value, if not set it adds the permission to the scope. task-4719790 Forward-Port-Of: odoo/enterprise#84032
…Inter-Company sync ### Steps to reproduce: - With Company B in the settings Enable Inter-Company Transactions > Synchronize Sales and Purchase Order - Sales > Configurations > Sales Teams, Archive all sales team - With COMP A create a sales team with a set company_id: COMP A - With COMP A create and confirm a PO with COMP B as customer #### > Invalid operation: while generating the SO, the sales team belongs to COMP A and the SO to COMP B. ### Cause of the issue: The `team_i
Original PR description
…Inter-Company sync ### Steps to reproduce: - With Company B in the settings Enable Inter-Company Transactions > Synchronize Sales and Purchase Order - Sales > Configurations > Sales Teams, Archive…
…Inter-Company sync ### Steps to reproduce: - With Company B in the settings Enable Inter-Company Transactions > Synchronize Sales and Purchase Order - Sales > Configurations > Sales Teams, Archive all sales team - With COMP A create a sales team with a set company_id: COMP A - With COMP A create and confirm a PO with COMP B as customer #### > Invalid operation: while generating the SO, the sales team belongs to COMP A and the SO to COMP B. ### Cause of the issue: The `team_id` field of the `sale.order` model is a stored pre-computed and company checked field. As such, when the SO is created and even if no sales team is provided to the create vals: https://github.com/odoo/enterprise/blob/c61ce5a8e46e706bfb2025d4c9c79a39598e8827/sale_purchase_inter_company_rules/models/purchase_order.py#L70 a default sales team will be computed and set on the SO based on the "allowed_company_ids" (including both COMP A and COMP B): https://github.com/odoo/odoo/blob/1fa8678a33ab35195005d1b65b5eecb1d089fe56/addons/sale/models/sale_order.py#L453-L460 https://github.com/odoo/odoo/blob/1fa8678a33ab35195005d1b65b5eecb1d089fe56/addons/sales_team/models/crm_team.py#L81-L88 While the domain checks that the sales team is either not tight to a company or belong to comp B, since no such teams were found, we fallback the invalid sales team of COMP A. The invalid operation is then raised during the `_check_company` of the created record. opw-4627851 Forward-Port-Of: odoo/enterprise#83487