Wednesday, January 3, 2024
29 changes · master
Resolved issues and error corrections
Badge award emails now hide unnecessary user signatures for portal or inactive users and remove the unwanted background frame. This makes recognition emails look cleaner and more professional for recipients.
Original PR description
**Before this PR:** - Portal user signature is visible in the badge email template. - Background color is visible in the badge email template. **After this PR:** - Portal user's signature is being made invisible in emails sent for earned badges. - Background color frame is being removed from the email template. **Task**-3384712
A project module test was corrected so it no longer fails because of year-specific date assumptions. This helps keep quality checks reliable over time without changing how users work with projects.
A previously disabled spreadsheet test has been turned back on after the underlying date-related issue was fixed. This improves ongoing quality checks for spreadsheet global filters without changing user-facing functionality.
Original PR description
This test has been skipped with 306803d17be32be19c029fb651ca125c1d447f87 because it was failing due the new year ("2023" was hardcoded in the test). After that, the test was fixed (6fafdbc9881803adec8a4333309bfade4801247a) but the skip was not removed.
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-prThis change corrects an internal payroll test so it handles year-related expectations properly. It helps keep payroll validation reliable and reduces the risk of future issues going unnoticed during development.
Features or functions removed from Odoo
This change removes a special testing shortcut that allowed dictionary comparisons to ignore missing keys. Keeping the test behavior simpler avoids hidden rules and unnecessary overhead in internal test checks.
Original PR description
This reverts commit 123a0285a23b2a11b98e21780a7c9af0b4e7c195. This is an hidden "feature" that may become a technical debt. This was adding an overhead on all dict comparison for one unique special case. https://github.com/odoo/enterprise/pull/53594
Code cleanup and technical improvements
This change reorganizes shared code that controls how popovers, dropdowns, autocomplete suggestions, and guided tour pointers are positioned on screen. It does not introduce new business functionality, but it makes the underlying interface code easier to maintain and safer to reuse across Odoo.
Miscellaneous changes
Prior to this commit, `ButtonBox` components were rendered inside `Dialog` ones. The approach created issues in the user flow, particularly in cases involving intermediary records that were not yet saved yet. task-3619180 Forward-Port-Of: odoo/odoo#146797
Original PR description
Prior to this commit, `ButtonBox` components were rendered inside `Dialog` ones. The approach created issues in the user flow, particularly in cases involving intermediary records that were not yet saved yet. task-3619180 Forward-Port-Of: odoo/odoo#146797
This update adjusts the Belgian reports posting wizard after a related change in the community version was reverted. It keeps the module aligned with the wider Odoo codebase and helps ensure existing reporting behavior remains stable.
Original PR description
…missing_keys__` Alternative solution of ef656039f6d31bd80c6c292051dc2fe7e5e8c66a, because of the revert in the community version. https://github.com/odoo/odoo/pull/147932
Before this commit, in a non-editable x2many in list mode, if there is a field "A" with many2many_tags which is displayed as an x2many in list mode in the form dialog, it cannot be reordered with handle field. Problem: When we extend a record from an x2many to a form dialog, we use the activeFields defined in the form view and patch them with those in the list view. Currently, we always use the default order from the list view even if it doesn't exist. So we always ignore the one defin
Original PR description
Before this commit, in a non-editable x2many in list mode, if there is a field "A" with many2many_tags which is displayed as an x2many in list mode in the form dialog, it cannot be reordered with…
Before this commit, in a non-editable x2many in list mode, if there is a field "A" with many2many_tags which is displayed as an x2many in list mode in the form dialog, it cannot be reordered with handle field. Problem: When we extend a record from an x2many to a form dialog, we use the activeFields defined in the form view and patch them with those in the list view. Currently, we always use the default order from the list view even if it doesn't exist. So we always ignore the one defined in the form view. Solution: If there is no default order in the list view, we use the one in the form view. How to reproduce: - Go to a form view with an x2many field in list mode which contains an "A" field with the many2many_tags widget. - Click on a record in the x2many - A form dialog opens with field "A" in the form of an x2many in list mode, containing a handle field. - drag and drop a line to reorder the records Before this commit: It is not possible to reorder records After this commit: It is possible to reorder records Task ID: 3641933 Forward-Port-Of: odoo/odoo#147253
Configure a product having category set with: - Costing Method: Average Cost (AVCO) - Inventory Valuation: Manual Create a purchase order with the product Confirm Receive Products Create bill (do not set date) Confirm Traceback will appear: 'AssertionError: convert amount from unknown date' It occurs because of an attempted currency conversion without a date As the bill is without date it should raise an UserError instead opw-3628295 Description of the issue/feature this PR a
Original PR description
Configure a product having category set with: - Costing Method: Average Cost (AVCO) - Inventory Valuation: Manual Create a purchase order with the product Confirm Receive Products Create bill (do not set date) Confirm Traceback will appear: 'AssertionError: convert amount from unknown date' It occurs because of an attempted currency conversion without a date As the bill is without date it should raise an UserError instead opw-3628295 Description of the issue/feature this PR addresses: Forward-Port-Of: odoo/odoo#147367 Forward-Port-Of: odoo/odoo#145592
This PR fixes two issues that occur when a customer has a very long name within the `point_of_sale` module. task-3631878 1. If you create a customer with a very long name, this will cause the left panel to extend, pushing the numpad to the right, making it out of use. To fix this issue, we add a `mw-50` class to the container, so that we limit its growth, and we validate the `text-truncate` class applied to the customer name. | 17.0 | 17.0-fix-pos-actionpad-width-chgo | | --
Original PR description
This PR fixes two issues that occur when a customer has a very long name within the `point_of_sale` module. task-3631878 1. If you create a customer with a very long name, this will cause the left…
This PR fixes two issues that occur when a customer has a very long name within the `point_of_sale` module. task-3631878 1. If you create a customer with a very long name, this will cause the left panel to extend, pushing the numpad to the right, making it out of use. To fix this issue, we add a `mw-50` class to the container, so that we limit its growth, and we validate the `text-truncate` class applied to the customer name. | 17.0 | 17.0-fix-pos-actionpad-width-chgo | | ------------- | ------------- | | <img alt="image" src="https://github.com/odoo/odoo/assets/128030743/37365f4c-32ba-4eba-a308-b34dfd559d20"> | <img alt="image" src="https://github.com/odoo/odoo/assets/128030743/6632aae0-21f4-48fa-8338-52fc0b43d582"> | 2. If you use the `point_of_sale` module on a mobile device, the buttons related to main actions such as refund, customer note, billing etc are wrapped into a `more` button. When you open that interface, if the name of the customer is too long, it will overflow the parent container and so generates an overflow. To fix that issue, we simply add a `text-truncate` class to the customer name to be sure it doesn't generate any overflow. | 17.0 | 17.0-fix-pos-actionpad-width-chgo | | ------------- | ------------- | | <img alt="image" src="https://github.com/odoo/odoo/assets/128030743/dfcbff9c-5763-429b-8fa3-fce7e4d68ab2"> | <img alt="image" src="https://github.com/odoo/odoo/assets/128030743/bb4c94bf-5cbf-4ae6-aa64-bbf6f80c6c86"> | Forward-Port-Of: odoo/odoo#145531
HOW TO REPRODUCE ================ - Don't need to login - From Odoo front-end, go to Courses > Trees, Wood and Gardens > Main Trees Categories - You get the following client error: Uncaught Promise > datetimeObj.getTime is not a function HOW TO SOLVE: ============ Unlike standard JS equivalent, luxon datetime objects don't have a getTime() function. Replace it by valueOf() function. Also, replace calls to `DateTime.fromJSDate().formatting_fn()` by luxon equivalent functions. tas
Original PR description
HOW TO REPRODUCE ================ - Don't need to login - From Odoo front-end, go to Courses > Trees, Wood and Gardens > Main Trees Categories - You get the following client error: Uncaught Promise > datetimeObj.getTime is not a function HOW TO SOLVE: ============ Unlike standard JS equivalent, luxon datetime objects don't have a getTime() function. Replace it by valueOf() function. Also, replace calls to `DateTime.fromJSDate().formatting_fn()` by luxon equivalent functions. task-3632077 see bb09cf76e32b20864dc45eacf912d2c6f26768ef --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#145573
Before this commit if invisible elements are in the DOM (e.g. device-visibility restricted) the arrows to move snippets (columns, sections) did show up and behave as if the neighbour elements were visible. This commit hides arrows that would not visually move the snippet, and upon using the move arrow, it also moves the snippet beyond the first visible neighbour. Steps to reproduce as of 16.0: - Drop a "Columns" snippet. - Make the center column hidden on desktop. - Move the first colum
Original PR description
Before this commit if invisible elements are in the DOM (e.g. device-visibility restricted) the arrows to move snippets (columns, sections) did show up and behave as if the neighbour elements were visible. This commit hides arrows that would not visually move the snippet, and upon using the move arrow, it also moves the snippet beyond the first visible neighbour. Steps to reproduce as of 16.0: - Drop a "Columns" snippet. - Make the center column hidden on desktop. - Move the first column to the right. => It did not move and an arrow to move to the left was displayed. Steps to reproduce before 16.0: - Drop three snippets. - Make the second snippet conditionally visible. - Hide it using the eye icon in the "Invisible Elements" list. - Move the first block down. => It did not move and an arrow to move upwards was displayed. task-3584947 Forward-Port-Of: odoo/odoo#146879 Forward-Port-Of: odoo/odoo#145895
The text overflow was causing the job title to overflow the kanban card and could create readability problems. This commit removes the text overflow and thus permit the job title to be displayed in full. task-3598895 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#142480
Original PR description
The text overflow was causing the job title to overflow the kanban card and could create readability problems. This commit removes the text overflow and thus permit the job title to be displayed in full. task-3598895 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#142480
An ormcache has been added to a method that takes lists as parameters but lists are not hashable. **steps to reproduce:** - go to apps and click on on 'Industries' **before this commit:** - a warning is raised in the logs: ``` WARNING industry odoo.tools.cache: cache lookup error on ('ir.module.module', <function IrModule._get_modules_from_apps at 0x7f99e842fc70>, ['icon', 'icon_flag', 'to_buy', 'name', 'state', 'summary', 'website', 'application', 'module_type', 'shortdesc'], 'indus
Original PR description
An ormcache has been added to a method that takes lists as parameters but lists are not hashable. **steps to reproduce:** - go to apps and click on on 'Industries' **before this commit:** - a warning…
An ormcache has been added to a method that takes lists as parameters but lists are not hashable.
**steps to reproduce:**
- go to apps and click on on 'Industries'
**before this commit:**
- a warning is raised in the logs:
```
WARNING industry odoo.tools.cache: cache lookup error on ('ir.module.module', <function IrModule._get_modules_from_apps at 0x7f99e842fc70>, ['icon', 'icon_flag', 'to_buy', 'name', 'state', 'summary', 'website', 'application', 'module_type', 'shortdesc'], 'industries', False, ['&', '!', ['name', '=like', 'theme_%'], '&', ['application', '=', True], ['module_type', '=', 'industries']], 80, 0) Traceback (most recent call last):
File "/home/nda/dev/odoo/17.0/odoo/odoo/tools/cache.py", line 99, in lookup
r = d[key]
File "<decorator-gen-5>", line 2, in __getitem__
File "/home/nda/dev/odoo/17.0/odoo/odoo/tools/func.py", line 87, in locked
return func(inst, *args, **kwargs)
File "/home/nda/dev/odoo/17.0/odoo/odoo/tools/lru.py", line 34, in __getitem__
a = self.d[obj]
TypeError: unhashable type: 'list'
```
**after this commit:**
- ormcache is properly used
opw-3660052
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#147730Current behaviour: --- When changing the text color in the document layout of the company to one of the first row colors, the text stays black in the preview of the document. Steps to reproduce: --- 1. Go to Settings 2. Click on Configure Document Layout 3. In Company Details, highlight the text 4. Change the font color to any of the first row 5. (By example the color #35979c) 6. The text color in the preview is still black 7. (Same when exporting to PDF) Cause of the issue:
Original PR description
Current behaviour: --- When changing the text color in the document layout of the company to one of the first row colors, the text stays black in the preview of the document. Steps to reproduce: --- 1. Go to Settings 2. Click on Configure Document Layout 3. In Company Details, highlight the text 4. Change the font color to any of the first row 5. (By example the color #35979c) 6. The text color in the preview is still black 7. (Same when exporting to PDF) Cause of the issue: --- The css code for colors in top row (o-color-1 to 6) is generated in web_editor (.text-o-color-1 to 6) and was not in the report_assets_common bundle See: https://github.com/odoo/odoo/blob/01b42c7d76c814e13325f8880dc9de765b0f43c8/addons/web_editor/static/src/scss/web_editor.common.scss#L662 opw-3360456 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#136566
Before this commit, since we are no longer in 2023, the test failed because there is no longer 2021 in the filters dynamically added in the dropdown of the date filter. The reason is now we have the current year, the previous one, and the one before, that is, 2024, 2023, 2022. This commit adds a patchDate to be sure we will start the test in 2023, to get the expected filters displayed (2023, 2022, 2021). Forward-Port-Of: odoo/odoo#147862 Forward-Port-Of: odoo/odoo#147824
Original PR description
Before this commit, since we are no longer in 2023, the test failed because there is no longer 2021 in the filters dynamically added in the dropdown of the date filter. The reason is now we have the current year, the previous one, and the one before, that is, 2024, 2023, 2022. This commit adds a patchDate to be sure we will start the test in 2023, to get the expected filters displayed (2023, 2022, 2021). Forward-Port-Of: odoo/odoo#147862 Forward-Port-Of: odoo/odoo#147824
There are various cases where we observe crons which systematically face a CPU / memory limit. In a setup where a single worker cron is launched, a failing cron will prevent subsequent crons to run. This happens because the limits are evaluated at the worker level: the worker is killed, then it starts over with the same job order. If the vacuum cron cannot be run anymore, it leads to tables not garbage collected anymore (e.g. `bus_bus`), causing performance issues. To avoid this, we give a
Original PR description
There are various cases where we observe crons which systematically face a CPU / memory limit. In a setup where a single worker cron is launched, a failing cron will prevent subsequent crons to run. This happens because the limits are evaluated at the worker level: the worker is killed, then it starts over with the same job order. If the vacuum cron cannot be run anymore, it leads to tables not garbage collected anymore (e.g. `bus_bus`), causing performance issues. To avoid this, we give a higher priority to the vacuum cron. 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#144210
242: These future expenses must be deferred on the company’s balance sheet until the moment in time they can be recognized, at once or over a defined period, on the Profit and Loss statement. 6274, 6414, 6424: Fixed asset depreciation not expense 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
Original PR description
242: These future expenses must be deferred on the company’s balance sheet until the moment in time they can be recognized, at once or over a defined period, on the Profit and Loss statement. 6274, 6414, 6424: Fixed asset depreciation not expense 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#146802
The Settings page lacks a default search context key, because it lacks the `<search>` arch. We add a context key to make actions target some specific settings. Needed for this PR, to point the user to the current Setting from a list of warnings (ActionableErrors widget): https://github.com/odoo/odoo/pull/142596 Forward-Port-Of: odoo/odoo#147149
Original PR description
The Settings page lacks a default search context key, because it lacks the `<search>` arch. We add a context key to make actions target some specific settings. Needed for this PR, to point the user to the current Setting from a list of warnings (ActionableErrors widget): https://github.com/odoo/odoo/pull/142596 Forward-Port-Of: odoo/odoo#147149
This PR adds the possibility for the `.o_horizontal` class to wrap, which is especially interesting in mobile. task-3580082 When using a `radio` widget, you can choose to use two options : - `horizontal` which will add a `.o_horizontal` class to the radios and allow them to display with a `flex-row` - `vertical` which will add a `.o_vertical` class to the radios and allow them to display with a `flex-column` Prior to this commit, the `.o_horizontal` class was not allowing elements
Original PR description
This PR adds the possibility for the `.o_horizontal` class to wrap, which is especially interesting in mobile. task-3580082 When using a `radio` widget, you can choose to use two options : -…
This PR adds the possibility for the `.o_horizontal` class to wrap, which is especially interesting in mobile. task-3580082 When using a `radio` widget, you can choose to use two options : - `horizontal` which will add a `.o_horizontal` class to the radios and allow them to display with a `flex-row` - `vertical` which will add a `.o_vertical` class to the radios and allow them to display with a `flex-column` Prior to this commit, the `.o_horizontal` class was not allowing elements to wrap, which would cause overflow issues on small devices. To fix this issue, we add a `flex-wrap` property to the class, to ensure that if the buttons are larger than the breakpoint, they will wrap and stay inside the container. | 17.0 | 17-0-fix-planning-alert-radio-btn-chgo | | ------------- | ------------- | | <img alt="image" src="https://github.com/odoo/odoo/assets/128030743/85e23989-8c40-4e1c-b165-106187acd088"> | <img alt="image" src="https://github.com/odoo/odoo/assets/128030743/4f751fd8-d91a-4d69-91ea-f23a16ff5a60"> | Forward-Port-Of: odoo/odoo#140651
**Steps:** - Open Field Service - Create a new task - At first, the product stat button shows the price as 0.00 - Add task name and customer - Save the task. - Check product stat button **Issue:** - Now, after saving the task, the product stat button will not have the price shown as it was displayed before. **Cause:** - The class o_field_empty is applied which has the property of display: none and hence the price field is not displayed. **Fix:** - The o_field_empty class is app
Original PR description
**Steps:** - Open Field Service - Create a new task - At first, the product stat button shows the price as 0.00 - Add task name and customer - Save the task. - Check product stat button **Issue:** - Now, after saving the task, the product stat button will not have the price shown as it was displayed before. **Cause:** - The class o_field_empty is applied which has the property of display: none and hence the price field is not displayed. **Fix:** - The o_field_empty class is applied at the wrong place, we need to apply the o_field_empty only when o_stat_text is applied. **Task:** 3394985 Forward-Port-Of: odoo/odoo#127248
Minor fix: the background grid is not observed in the first place, setting a z-index on it should not be observed either. Noticed when fixing `automaticStep(Un)active()` at [1]. [1]: https://github.com/odoo/odoo/commit/c2d952689c97add74a372c90aa18787094d5d93a Related to task-3576046 Forward-Port-Of: odoo/odoo#146816
Original PR description
Minor fix: the background grid is not observed in the first place, setting a z-index on it should not be observed either. Noticed when fixing `automaticStep(Un)active()` at [1]. [1]: https://github.com/odoo/odoo/commit/c2d952689c97add74a372c90aa18787094d5d93a Related to task-3576046 Forward-Port-Of: odoo/odoo#146816
Forward-Port-Of: odoo/enterprise#51814
Original PR description
Forward-Port-Of: odoo/enterprise#51814
When an offer is generated from an existing contract, the initial value for the hospital and ambulatory cost is takend from the previous contract. If the cost for an adult and/or a children is changed in the system parameters is changed, it is not taken into account for offers comming from an existing contract having already insurance amount. So we recompute the cost of the insurance based on the system config parameter values. Forward-Port-Of: odoo/enterprise#53535
Original PR description
When an offer is generated from an existing contract, the initial value for the hospital and ambulatory cost is takend from the previous contract. If the cost for an adult and/or a children is changed in the system parameters is changed, it is not taken into account for offers comming from an existing contract having already insurance amount. So we recompute the cost of the insurance based on the system config parameter values. Forward-Port-Of: odoo/enterprise#53535
Issue: ====== There is a traceback when going to next document in sign. Steps to reproduce the issue: ============================= - Install sign - Upload 2 pdf files - Add any sign item - Click send and add any customer - Click on next document Origin: ======= The params of the action are in the wrong format. opw-3645674 Forward-Port-Of: odoo/enterprise#53422
Original PR description
Issue: ====== There is a traceback when going to next document in sign. Steps to reproduce the issue: ============================= - Install sign - Upload 2 pdf files - Add any sign item - Click send and add any customer - Click on next document Origin: ======= The params of the action are in the wrong format. opw-3645674 Forward-Port-Of: odoo/enterprise#53422
This commit adapts the tests to be more robust when the current year change to avoid error in test as the click on the datepicker is calculated and not fixed. Forward-Port-Of: odoo/enterprise#53563 Forward-Port-Of: odoo/enterprise#53538
Original PR description
This commit adapts the tests to be more robust when the current year change to avoid error in test as the click on the datepicker is calculated and not fixed. Forward-Port-Of: odoo/enterprise#53563 Forward-Port-Of: odoo/enterprise#53538
Make basic rights for administrator to gives them permissions to delete approval requests before it was limited to the domain for officer (i.e. only your own approval). The products was also preventing the deletion of the approvals thus the unlink method had to be rewritten to make it possible. task-3463942 Forward-Port-Of: odoo/enterprise#51966 Forward-Port-Of: odoo/enterprise#51002
Original PR description
Make basic rights for administrator to gives them permissions to delete approval requests before it was limited to the domain for officer (i.e. only your own approval). The products was also preventing the deletion of the approvals thus the unlink method had to be rewritten to make it possible. task-3463942 Forward-Port-Of: odoo/enterprise#51966 Forward-Port-Of: odoo/enterprise#51002
When attempting to create a user using the pos_blackbox_be module, an error arises due to an issue in the log creation process. This commit ensures that the creation process is now functioning correctly. Forward-Port-Of: odoo/enterprise#52797
Original PR description
When attempting to create a user using the pos_blackbox_be module, an error arises due to an issue in the log creation process. This commit ensures that the creation process is now functioning correctly. Forward-Port-Of: odoo/enterprise#52797