Wednesday, January 3, 2024
40 changes · master
Enhancements to existing features
This change updates the Mass Mailing mobile preview so email content is displayed in a more isolated and reliable preview area. This helps business users review campaigns more accurately before sending, reducing the risk of layout surprises on mobile devices.
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
Website editors can now use gradient backgrounds in color presets, giving businesses more flexible visual branding options without custom code. The update also improves editor reliability by handling named colors in gradients and preventing conflicting option changes while updates are being applied.
Original PR description
Before this commit color presets for background could not use gradients. After this commit color presets for background can use gradients. task-2633169
HR users can now archive and unarchive skill types, with archived types removed from active employee and appraisal skill views except completed appraisals. An Archived filter and visual ribbon make it easier to manage outdated or inactive skill categories without deleting their related skills or levels.
Original PR description
Problem:
-------------
Currently, user cannot archive skill types
What we achieved in this commit:
----------------------
- If the user archives the skill type, it will be removed from the employee and
appraisal except done stage.
- add Archived filter
Technical:
------------
When we archive the skill type, we do not archive the skill and skill level
because when we open the archived skill type, the level and skill are not visible.
task-3385297The organization chart view now supports the search filter menu, making it easier for users to narrow down the people or records they need. This also restores a related search bar styling change to avoid visual issues seen elsewhere while keeping the interface consistent.
Original PR description
task-3582032
The web barcode scanning component now uses a newer barcode recognition library and includes adjustments to keep scanning behavior reliable. Barcodes should be easier to detect consistently thanks to better image contrast and compatibility handling.
Original PR description
In this commit: * We update the ZXing barcode recognition library to v0.20.0 Changelogs: 0.19.3 [1] - 0.20.0 [2] * Monkey-patch the lib to revert [3], because the new behavior of the lib doesn't work when the `ZXing.DecodeHintType.TRY_HARDER` flag is set at true * We also add a white background to the canvas to ensure proper contrast between the barcode in itself (black) and the background (white). [1]: https://github.com/zxing-js/library/releases/tag/v0.19.3 [2]: https://github.com/zxing-js/library/releases/tag/v0.20.0 [3]: https://github.com/zxing-js/library/commit/7644e279df9fd2e754e044c25f450576d2878e45 task-3600472
Custom product variant descriptions created from sales orders are now carried through to the shop floor view. This helps production teams see the same specific product details already available on manufacturing orders, reducing confusion during make-to-order work.
Original PR description
When using MTO, a custom attribute value can be created in a sale order. The custom value is then visible on the manufacturing order, but is not in the shop floor. This commit fix it.
Point of Sale add-ons now use a shared frontend data model that makes related information easier and more consistent to access. This supports smoother maintenance and more reliable behavior across localization, hardware, restaurant, payment, and messaging POS features, with an additional fix for preparation display data storage.
Archived skill types are no longer shown on employee and appraisal skill views, except where appraisals are already completed. Appraisal Skills Reports now use only active skill types, helping teams keep evaluations current and avoid outdated skill categories.
Original PR description
Problem:
---------------
Currently, user cannot archive skill types
What we achieved in this commit:
--------------
- If the user archives the skill type, it will be removed from the employee and
appraisal except the done stage.
- Add archived filter
- Only active skill types will be utilized when the user creates an Appraisal Skills Report.
Technical:
----------------
When we archive the skill type, we do not archive the skill and skill level because when
we open the archived skill type, the level and skill are not visible.
task-3385297Contract salary offers can no longer include a company car option for companies outside Belgium. This keeps salary offer options aligned with Belgian-specific rules and reduces the risk of offering an inapplicable benefit in other countries.
Original PR description
Change removes possibility of adding car to contract offers in companies other than BE ones task-3471266
The Approvals app now lets users filter requests by approved, refused, or canceled status and group requests by status. This makes it faster for managers and employees to review approval activity and focus on the requests that need attention.
Original PR description
- Add filters 'Approved', 'Refused', and 'Canceled' - Add group-by status option Task: 3631957
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
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
Point of Sale now uses a more connected frontend data structure, making sales, payments, products, and localization data easier for the system to keep in sync. This improves the foundation for faster, more reliable POS features across many country-specific and payment integrations, with limited direct impact on day-to-day users.
Original PR description
## First commit: *:l10n_ar_pos,l10n_co_pos,l10n_es_pos,l10n_fr_pos_cert,l10n_gcc_pos, l10n_in_pos,l10n_sa_pos,pos_adyen,pos_mercury,pos_online_payment,…
## First commit: *:l10n_ar_pos,l10n_co_pos,l10n_es_pos,l10n_fr_pos_cert,l10n_gcc_pos, l10n_in_pos,l10n_sa_pos,pos_adyen,pos_mercury,pos_online_payment, pos_online_payment_self_order,pos_paytm,pos_restaurant, pos_restaurant_adyen,pos_restaurant_stripe,pos_sale, pos_sale_product_configurator,pos_self_order,pos_six,pos_stripe, pos_viva_wallet,product This commit adds a new relational system to the data loaded from the server. With Odoo's ORM in python, when you have a `pos_order`, for example, you can directly access the command lines via `pos_order.lines`. The aim here is to be able to do the same thing in the Point of Sale frontend. How it works: -All data is loaded into the `pos_data` service (`data_service.js`), then this service will load the data into the relational model system. - All this data can then be accessed via the `pos_store`. - All RPC calls must pass through the data_service in order to automatically update the relational models. Example: ``` const pos_order = this.pos.models["pos.order"].getAll(); const lineProducts = pos_order.lines.map((l) => l.product); ``` Data can now be accessed in a similar way to the ORM backend. Related Models: https://github.com/caburj/RelatedModels
Original PR description
*:l10n_cl_edi_pos,l10n_de_pos_cert,l10n_de_pos_res_cert,l10n_mx_edi_pos, pos_blackbox_be,pos_iot,pos_iot_six,pos_l10n_se,pos_preparation_display,…
*:l10n_cl_edi_pos,l10n_de_pos_cert,l10n_de_pos_res_cert,l10n_mx_edi_pos, pos_blackbox_be,pos_iot,pos_iot_six,pos_l10n_se,pos_preparation_display, pos_restaurant_appointment,pos_settle_due,whatsapp_pos This commit adds a new relational system to the data loaded from the server. With Odoo's ORM in python, when you have a `pos_order`, for example, you can directly access the command lines via `pos_order.lines`. The aim here is to be able to do the same thing in the Point of Sale frontend. How it works: -All data is loaded into the `pos_data` service (`data_service.js`), then this service will load the data into the relational model system. - All this data can then be accessed via the `pos_store`. - All RPC calls must pass through the data_service in order to automatically update the relational models. Example: ``` const pos_order = this.pos.models["pos.order"].getAll(); const lineProducts = pos_order.lines.map((l) => l.product); ``` Data can now be accessed in a similar way to the ORM backend.
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.
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