Wednesday, July 24, 2024
26 changes · saas-17.2
Enhancements to existing features
The HR module’s automated tests were updated to use Odoo’s newer HOOT testing approach instead of older QUnit-based utilities. This is an internal quality improvement that helps keep testing reliable and easier to maintain, with no expected change for everyday users.
Original PR description
Update legacy tests importing mail/test_utils.js to use HOOT instead of Qunit. Task-3818666
The HR Skills app’s automated tests were moved to a newer testing framework. This helps the development team maintain quality more efficiently without changing the user-facing HR features.
Original PR description
This commit aims to convert QUnit tests which rely on hr_skills/test_utils to hoot. Part of Task-3818666 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This fixes an issue in the web testing framework where modules could be allowed based on partial name matches. The change ensures only exact addon names are accepted, reducing the risk of incorrect test modules being started.
Original PR description
Before this PR, to filter modules that a module set required, the addon name was searched within the list of allowed addons *stringified and joined* with a simple call to "includes", which means that a partial match with an addon's name would allow the module to be started. This has been fixed by checking that the full addon's name appears in the list of allowed addons. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
A company that is carrying out a project financed with public money has the obligation to have the CUP code (and also the CIG) indicated on the purchase invoices. For non-PA customers, those fields are visible but not required and when filled in, will be presented in the XML. task-4032771 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173682
Original PR description
A company that is carrying out a project financed with public money has the obligation to have the CUP code (and also the CIG) indicated on the purchase invoices. For non-PA customers, those fields are visible but not required and when filled in, will be presented in the XML. task-4032771 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173682
The spreadsheet component was updated to the latest available version for this Odoo release. This fixes a visual issue where cell A1 appeared hovered by default, making spreadsheet interactions clearer for users.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/6c6574338 [REL] 17.2.18 Task: 0 https://github.com/odoo/o-spreadsheet/commit/2e866045f [FIX] grid_overlay: A1 is hovered by default Task: 4042621 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: 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>
Have a partner with district filled Create a Sale Order Print report Issue: District is missing opw-4020494 Forward-Port-Of: odoo/odoo#173166 Forward-Port-Of: odoo/odoo#172323
Original PR description
Have a partner with district filled Create a Sale Order Print report Issue: District is missing opw-4020494 Forward-Port-Of: odoo/odoo#173166 Forward-Port-Of: odoo/odoo#172323
Specification: In the daterange widget, if the second date field is required and left empty, the field should be marked as invalid and be colored red. Expected behavior: if the second field is empty so that fields should be highlighted in red. Task-3786540 Forward-Port-Of: odoo/odoo#162000
Original PR description
Specification: In the daterange widget, if the second date field is required and left empty, the field should be marked as invalid and be colored red. Expected behavior: if the second field is empty so that fields should be highlighted in red. Task-3786540 Forward-Port-Of: odoo/odoo#162000
Before this commit : In Draft Invoice/bill if we change fiscal position then it's not updating tax and account in existing lines. After this commit : In the Draft Invoice/bill if we change in fiscal position then it will update the tax and account in existing lines. Task - 3619055 Forward-Port-Of: odoo/odoo#153172
Original PR description
Before this commit : In Draft Invoice/bill if we change fiscal position then it's not updating tax and account in existing lines. After this commit : In the Draft Invoice/bill if we change in fiscal position then it will update the tax and account in existing lines. Task - 3619055 Forward-Port-Of: odoo/odoo#153172
[IMP] l10n_cz: Fill accounting date with 'taxable_supply_date' In CZ, they need to use the taxable supply date as accounting date and rely on it when we are calculating the currency rate 1- Set default value for 'taxable_supply_date' as the invoice date and allow the user to modify it. Also, fill the accounting date but using the taxable supply date as reference in place of invoice date. 2- Use taxable_supply_date/accounting date to compute the currency rate task-id#3983749 enterpr
Original PR description
[IMP] l10n_cz: Fill accounting date with 'taxable_supply_date' In CZ, they need to use the taxable supply date as accounting date and rely on it when we are calculating the currency rate 1- Set default value for 'taxable_supply_date' as the invoice date and allow the user to modify it. Also, fill the accounting date but using the taxable supply date as reference in place of invoice date. 2- Use taxable_supply_date/accounting date to compute the currency rate task-id#3983749 enterprise-pr: https://github.com/odoo/enterprise/pull/67149 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168933
Steps: - Create group tax (20%) and add two tax in it (10% each) with Tax included true. - Create product with 100 price and and set that 20% tax on it. - Create coupon program with 90 amount on order and generate coupon. - Create SO and add SOL with that product now apply coupon on that SO. Issue: - Amount computation is wrong for coupon value which is greater then that product's tax_excluded(80) and it is only applying 80 instead of 90 because we were not properly computing amount
Original PR description
Steps: - Create group tax (20%) and add two tax in it (10% each) with Tax included true. - Create product with 100 price and and set that 20% tax on it. - Create coupon program with 90 amount on order and generate coupon. - Create SO and add SOL with that product now apply coupon on that SO. Issue: - Amount computation is wrong for coupon value which is greater then that product's tax_excluded(80) and it is only applying 80 instead of 90 because we were not properly computing amount of child taxed. Cause: - Discountable was not properly computed in commit [1]. it was not taking child tax values into account. Fix: - Add condition to properly check discountable values and take child tax amount into consideration. [1] https://github.com/odoo/odoo/commit/443097b4db29a4909bb0d0c44040140f08d1e433 opw-4033803 Forward-Port-Of: odoo/odoo#174196 Forward-Port-Of: odoo/odoo#173659
This commit adds the missing neutralization necessary for the l10n_ro_efactura module introduced in [1] The purpose of the standard neutralization framework is to allow us to create database copies that will not interact with external systems in ways that could impact the production database (or if it is not possible to prevent the interactions, make sure that they are benign or won't result in actual changes), or impact the customers of the operator of the production database. This is mainly
Original PR description
This commit adds the missing neutralization necessary for the l10n_ro_efactura module introduced in [1] The purpose of the standard neutralization framework is to allow us to create database copies that will not interact with external systems in ways that could impact the production database (or if it is not possible to prevent the interactions, make sure that they are benign or won't result in actual changes), or impact the customers of the operator of the production database. This is mainly useful to allow safe support investigation on database duplicates. [1] https://github.com/odoo/odoo/pull/144061 Forward-Port-Of: odoo/odoo#174013
Steps to reproduce: - Create a storable product. - Create a picking with it and validate. - Try to change the product type to consumable. Not allowed because there is a move done. - Archive the product. - Try to change the product type. No user error is raised... Excepted behaviour: It should not be possible to change the product type even if the product is archived, as it causes inconsistencies. Task 4058450 --- I confirm I have signed the CLA and read the PR guidelines at www.od
Original PR description
Steps to reproduce: - Create a storable product. - Create a picking with it and validate. - Try to change the product type to consumable. Not allowed because there is a move done. - Archive the product. - Try to change the product type. No user error is raised... Excepted behaviour: It should not be possible to change the product type even if the product is archived, as it causes inconsistencies. Task 4058450 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173901 Forward-Port-Of: odoo/odoo#173526
In its override of res_partner, the module introduces 2 new stored compute fields, which trigger a slow recompute at install time. Since those computations need to happen at some point to ensure that the module is working properly, changing the compute method was not an option. The changes proposed in this commit bypass the compute during the installation, leading to more reasonable install times (from an estimated 59 days down to about 1 min in our encountered case). A notable caveat i
Original PR description
In its override of res_partner, the module introduces 2 new stored compute fields, which trigger a slow recompute at install time. Since those computations need to happen at some point to ensure that the module is working properly, changing the compute method was not an option. The changes proposed in this commit bypass the compute during the installation, leading to more reasonable install times (from an estimated 59 days down to about 1 min in our encountered case). A notable caveat is that the users will have to trigger this computation manually record by record or in small batches. For smaller DBs, this shouldn't be an issue. For larger DBs, since the alternative is to not use the module at all or start from scratch with a new DB, the proposed solution seems acceptable. opw-4027267 Forward-Port-Of: odoo/odoo#172914
In the POS Restaurant module, there was an issue where an order could be missed in the backend if a draft order, opened by a cashier on one device, was paid for on another device. Subsequently, if the cashier added more products to the order and completed the payment, the receipt would be printed, but the backend would fail to record the updated order. This fix ensures that an updated order with the same reference is captured in the backend if its content has changed, preventing data loss and en
Original PR description
In the POS Restaurant module, there was an issue where an order could be missed in the backend if a draft order, opened by a cashier on one device, was paid for on another device. Subsequently, if the cashier added more products to the order and completed the payment, the receipt would be printed, but the backend would fail to record the updated order. This fix ensures that an updated order with the same reference is captured in the backend if its content has changed, preventing data loss and ensuring consistency across devices. opw-4067875 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174200
**Steps:** - Create a new Discount and loyalty program. - Keep the program type as Buy X Get Y / any other program - In the rewards pop-up, leave the 'description on the product' empty and click on 'save & close'. - Try to save the loyalty program. Validation error appears. **Cause:** - This occurs because the description is used to set the name of the discount product, but if it's empty, the write method will not get the proper values hence resulting in error. **Fix:** - Raise user
Original PR description
**Steps:** - Create a new Discount and loyalty program. - Keep the program type as Buy X Get Y / any other program - In the rewards pop-up, leave the 'description on the product' empty and click on 'save & close'. - Try to save the loyalty program. Validation error appears. **Cause:** - This occurs because the description is used to set the name of the discount product, but if it's empty, the write method will not get the proper values hence resulting in error. **Fix:** - Raise user error if the description field is set to empty. **Affected Version:** 16.0 - saas~17.4 **opw**-4032798 Forward-Port-Of: odoo/odoo#173789
Allow customization to retrieve the user used to authenticate by adding the user attribute. opw-4059147 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174208
Original PR description
Allow customization to retrieve the user used to authenticate by adding the user attribute. opw-4059147 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174208
Summary ----- In the method load in models.py, when there is an error when we try to create a recordset with at least 2 records, we try to create each record separately. Only the errors caught by creating these single records are displayed which is confusing. Steps to Reproduce ----- 1. In Accounting > Configuration > Accounting > Chart of Accounts, create an account with the type "Off-Balanced Sheet" 2. On the same page, import a Chart of Account (import journal items
Original PR description
Summary ----- In the method load in models.py, when there is an error when we try to create a recordset with at least 2 records, we try to create each record separately. Only the errors caught by…
Summary
-----
In the method load in models.py, when there is an error when we try to create a recordset with at least 2 records, we try to create each record separately.
Only the errors caught by creating these single records are displayed which is confusing.
Steps to Reproduce
-----
1. In Accounting > Configuration > Accounting > Chart of
Accounts, create an account with the type "Off-Balanced Sheet"
2. On the same page, import a Chart of Account (import journal
items) by uploading a file which contains the following lines
(example available on the ticket):
[
['move_id','account_id','balance' 'journal_id','date'],
[<move_name>,<account_code_1>,1,<journal_name>,2021-01-01],
[<move_name>,<account_code_2>,-1,<journal_name>,2021-01-01]
]
such that:
- move_name cannot exist
account_code_1 is the code of the created account at
first step
account_code_2 is not the code of an account with the
type "Off-Balanced Sheet"
- journal_name is the name of an existing journal
3. Test or import the uploaded file and see the error which does
not mention the "Off-Balanced Sheet" account.
Cause
-----
If a journal entry contains a line with an "Off
Balanced Sheet" account, then all the other lines must have an account with the same type.
So when we try to load the lines of the uploaded file, it raises a UserError which is caught (which is not added to the list 'messages'). Then we try to create the lines one by one which and that raises an error too because the balance is not null.
Only these errors are added to the list 'messages' which contains the displayed error messages.
Fix
-----
Add the first error to 'message', and ensure that the next errors are not already in 'messages'.
opw-3945687
Forward-Port-Of: odoo/odoo#169083Versions: --------- - 16.0 Steps to reproduce: ------------------- - go to the planning calendar. - hover over a record in the sidebar of the calendar, and then - click on "Shifts" in the calendar entries. Issue: ------ 1. the size of the popover enlarges when the content of the field is large, and the child element does not inherit the width of its parent elements. 2. The size of the popover becomes larger when hovering over the calendar filter tooltip. Cause: ------ Th
Original PR description
Versions: --------- - 16.0 Steps to reproduce: ------------------- - go to the planning calendar. - hover over a record in the sidebar of the calendar, and then - click on "Shifts" in the calendar entries. Issue: ------ 1. the size of the popover enlarges when the content of the field is large, and the child element does not inherit the width of its parent elements. 2. The size of the popover becomes larger when hovering over the calendar filter tooltip. Cause: ------ The popover title is taking up the full 100% width. Additionally, the popover title and body expand in response to the content of the fields, causing the popover size to become larger. Solution: --------- Setting a maximum width and enabling text truncation will make it appear more visually appealing. Additionally, set a maximum width of 25% and enable text truncation." **task-3446307** Forward-Port-Of: odoo/odoo#173203 Forward-Port-Of: odoo/odoo#138336
Pre-authorized debit payments in Canada are using Automated Clearing Settlement System (ACSS), which our current integration does not support. opw-4012861 Forward-Port-Of: odoo/odoo#173587
Original PR description
Pre-authorized debit payments in Canada are using Automated Clearing Settlement System (ACSS), which our current integration does not support. opw-4012861 Forward-Port-Of: odoo/odoo#173587
- Changed pos_display background to follow odoo 17's default one, updated all colors/logo to fit, - Moved error message to console as it's almost never relevant to users, - Added hostname on top of the page. Task: 3947355 Forward-Port-Of: odoo/odoo#174169
Original PR description
- Changed pos_display background to follow odoo 17's default one, updated all colors/logo to fit, - Moved error message to console as it's almost never relevant to users, - Added hostname on top of the page. Task: 3947355 Forward-Port-Of: odoo/odoo#174169
**Current behavior before PR:** When initiating searches quickly in discuss channels or chatter, overlapping requests can occur before previous searches finish. This race condition leads to errors and causes issues with destructuring properties like count, loadMore, and messages.( see: [Discuss](https://www.awesomescreenshot.com/video/29801496?key=44057f8e37a2f394f20e8fc790f80537)) **Desired behavior after PR is merged:** This commit updates the `useMessageSearch` hook to handle sim
Original PR description
**Current behavior before PR:** When initiating searches quickly in discuss channels or chatter, overlapping requests can occur before previous searches finish. This race condition leads to errors and causes issues with destructuring properties like count, loadMore, and messages.( see: [Discuss](https://www.awesomescreenshot.com/video/29801496?key=44057f8e37a2f394f20e8fc790f80537)) **Desired behavior after PR is merged:** This commit updates the `useMessageSearch` hook to handle simultaneous requests more robustly by checking that search results are defined before processing them. This prevents errors and improves stability during rapid searches. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174174
[REV] project: set default value of analytic plan in the project config setting This reverts commit https://github.com/odoo/odoo/commit/a2c51c6ad9ae80e6d4edc5de96811edd56df7a7c because the `analytic.project_plan` should not be altered since that field is used to find the column auto-generated in `account.analytic.line` model by `analytic.plan`. opw-4051817 Forward-Port-Of: odoo/odoo#174259
Original PR description
[REV] project: set default value of analytic plan in the project config setting This reverts commit https://github.com/odoo/odoo/commit/a2c51c6ad9ae80e6d4edc5de96811edd56df7a7c because the `analytic.project_plan` should not be altered since that field is used to find the column auto-generated in `account.analytic.line` model by `analytic.plan`. opw-4051817 Forward-Port-Of: odoo/odoo#174259
Description of the issue/feature this PR addresses: This PR fixes the incorrect styling applied by the css when reporting the client_order_ref field. Current behavior before PR:  Desired behavior after PR is merged:  --- I confirm I have signed the CLA and read the PR guidelines at ww
Original PR description
Description of the issue/feature this PR addresses: This PR fixes the incorrect styling applied by the css when reporting the client_order_ref field. 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#172741 Forward-Port-Of: odoo/odoo#172366
In the mail composer, the title of the modal changes to "Odoo" when the user clicks on the "Save Template" button. This commit will ensure that the modal will keep the title "Compose email" after the user clicks on the button. Steps to reproduce the issue: 1. Open a lead from the CRM module 2. Open the mail composer from the chatter 3. In the composer, click on the "Save Template" button 4. Give a name for the new template => The modal title changes from "Compose Email" to "Odoo" TO
Original PR description
In the mail composer, the title of the modal changes to "Odoo" when the user clicks on the "Save Template" button. This commit will ensure that the modal will keep the title "Compose email" after the…
In the mail composer, the title of the modal changes to "Odoo" when the user clicks on the "Save Template" button. This commit will ensure that the modal will keep the title "Compose email" after the user clicks on the button. Steps to reproduce the issue: 1. Open a lead from the CRM module 2. Open the mail composer from the chatter 3. In the composer, click on the "Save Template" button 4. Give a name for the new template => The modal title changes from "Compose Email" to "Odoo" TO BE: The modal title should display "Compose Email" after creating the template. After creating the template, the system re-opens the composer by executing a dynamic action. This action does not specify any title. As a result, the modal fallbacks to the default title "Odoo" after executing the action. To fix the issue, we will simply set a name to the dynamic action. task-3748652 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173135 Forward-Port-Of: odoo/odoo#172765
Some fields related to Italian invoicing are included in XML but missing from the invoice PDF. Added these fields to report_invoice for users to have more visibility for what's included in the XML submitted to Sdl. Task [link](https://www.odoo.com/odoo/project.task/3794551) task-3794551 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168447
Original PR description
Some fields related to Italian invoicing are included in XML but missing from the invoice PDF. Added these fields to report_invoice for users to have more visibility for what's included in the XML submitted to Sdl. Task [link](https://www.odoo.com/odoo/project.task/3794551) task-3794551 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168447
Before this PR, when selecting a new date in a date(time)_field, the value would first be reset before performing the "onchange" call, resulting in a flicker (selected value -> null -> new value after onchange). Now, the value is not reset and is simply left as selected when performing the onchange call, as to not trigger any flicker. Part of task [3471424](https://www.odoo.com/odoo/333/tasks/3471424) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit
Original PR description
Before this PR, when selecting a new date in a date(time)_field, the value would first be reset before performing the "onchange" call, resulting in a flicker (selected value -> null -> new value after onchange). Now, the value is not reset and is simply left as selected when performing the onchange call, as to not trigger any flicker. Part of task [3471424](https://www.odoo.com/odoo/333/tasks/3471424) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174326