Thursday, February 8, 2024
6 changes · 17.0
Enhancements to existing features
List views can now be configured so clicking a read-only cell does not automatically move focus to the next editable cell. This gives teams more control over editing behavior and helps avoid unexpected cursor jumps for users.
Original PR description
When clicking on a readonly cell in a list item, the next editable cell is automatically focused if any. This adds a parameter to disable that feature.
Scheduled background jobs now carry a clear indicator that they are running automatically. This helps Odoo adapt behavior for automated tasks, such as delayed email sending, without passing extra details through many internal steps.
Original PR description
Provide a new param cron_mode=True in context when calling the method. Instead to send param from method to method, or to be able to customize code in function that doesn't receive this param. From this way we can change code depending of the way it is called. e.g. Deferred send_mail, or ...
Resolved issues and error corrections
The payroll module's dashboard test was failing when the sign module wasn't installed, even though payroll doesn't require sign. This fix adds a check to only create sign-related test data when the sign module is actually available, ensuring tests run reliably regardless of which modules are installed.
Original PR description
Before this commit, the `test_dashboard_ui` test in payroll was relying on sign. However, `hr_payroll` does not depend on sign, which would lead to the test breaking when that module is not installed. This commit adds a check to see if sign is installed before creating the additional data related to it. Forward-Port-Of: odoo/enterprise#56051
Documentation and clarification updates
This pull request records the Contributor License Agreement (CLA) signature for MohdAlmosawy, a contributor to the Odoo project. This is a standard legal requirement that allows the contributor to submit code to the Odoo repository. The change simply adds documentation confirming that the contributor has signed the necessary legal agreement.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
If translation of '__export__' module record's source and translated value in 'en_US' language is different. In that case, record's value of 'en_US' lang is translated value. Also in most of the case export module records are set as noupdate false due to this while upgrading the database to version 16 from lower version, the record's value is changed to their source value for 'en_US' lang. To avoid this problem of updating a record's value, this PR will not considering '__export__' module rec
Original PR description
If translation of '__export__' module record's source and translated value in 'en_US' language is different. In that case, record's value of 'en_US' lang is translated value. Also in most of the case…
If translation of '__export__' module record's source and translated value in 'en_US' language is different. In that case, record's value of 'en_US' lang is translated value. Also in most of the case export module records are set as noupdate false due to this while upgrading the database to version 16 from lower version, the record's value is changed to their source value for 'en_US' lang.
To avoid this problem of updating a record's value, this PR will not considering '__export__' module records for translation updates. Hence,'__export__' module's records translation remain same as per original database.
Task : 3626386
Description of the issue/feature this PR addresses:
```
15_test_copy=> select id,name,res_id,noupdate,module from ir_model_data where module='__export__' and res_id=323;
id | name | res_id | noupdate | module
-------+-------------------------------+--------+----------+------------
18613 | product_template_145_b960fe0c | 323 | f | __export__
15_test_copy=> select * from ir_translation where name='product.template,name' and res_id=323;
id | name | res_id | lang | type | src | value | module | state | comments
-------+-----------------------+--------+--------+-------+-----------+--------------------+------------+------------+----------
39689 | product.template,name | 323 | ar_001 | model | moob test | moob test (ARABIC) | __export__ | translated |
39987 | product.template,name | 323 | hi_IN | model | moob test | moob test (HINDI) | __export__ | translated |
39690 | product.template,name | 323 | en_US | model | moob test | moob test (ENG) | __export__ | translated |
```
Current behavior before PR:
```
15_test_copy_16.0=> select id,name from product_template where id=323;
id | name
-----+--------------------------------------------------------------------------------------
323 | {"en_US": "moob test", "hi_IN": "moob test (HINDI)", "ar_001": "moob test (ARABIC)"}
```
Desired behavior after PR is merged:
```
15_test_copy_16.0=> select id,name from product_template where id=323;
id | name
-----+--------------------------------------------------------------------------------------------
323 | {"en_US": "moob test (ENG)", "hi_IN": "moob test (HINDI)", "ar_001": "moob test (ARABIC)"}
```
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#147682Steps to reproduce: ------------------- Create an accrual plan with 1 days every last day of the month. At the end of the year, unused accruals is postponed. Create an allocation that begins 1st November 2023. To be in mid-January 2024 and run the cron several times. The number of days is incremented like: 0.00 -> 1.97 -> 2.00 -> 2.03 -> 2.06 Issue: ------ Increasing plans do not behave as expected when they are spread over several years. If we create an accrual plan that gives all
Original PR description
Steps to reproduce: ------------------- Create an accrual plan with 1 days every last day of the month. At the end of the year, unused accruals is postponed. Create an allocation that begins 1st…
Steps to reproduce: ------------------- Create an accrual plan with 1 days every last day of the month. At the end of the year, unused accruals is postponed. Create an allocation that begins 1st November 2023. To be in mid-January 2024 and run the cron several times. The number of days is incremented like: 0.00 -> 1.97 -> 2.00 -> 2.03 -> 2.06 Issue: ------ Increasing plans do not behave as expected when they are spread over several years. If we create an accrual plan that gives allocations every month in 2023 and in 2024 we run the cron (several times), the number of days allocated to the allocation will always increment. Cause: ------ The following logic forces the nextcall to `date_to`, which is the first day of the current year. ```py if force_period and allocation.nextcall > date_to: allocation.nextcall = date_to force_period = False ``` Unfortunately, `lastcall` is still in the previous year. This will result in the allcation always being detected (in the `_update_accrual` method) as an `end_of_year_allocations`. If the accrual plan linked to this allocation is of type `postponed`, we will increment each time the cron is called with the proprata. Solution: --------- Force the lastcall on the first day of the current year for over years allocations which are of type `postponed` in order to obtain the remainder of the allocations (according to the prorata) at the next cron call. opw-3669893 Forward-Port-Of: odoo/odoo#152808