Friday, May 24, 2024
26 changes
1 change
Resolved issues and error corrections
This update fixes several issues in Odoo's internal HOOT testing tools and mock browser/server behavior. It helps developers run more reliable automated tests, reducing the risk of test failures unrelated to real product problems.
Original PR description
## Pull Request HOOT (PRHOOT) - part 15.5 Part 1: https://github.com/odoo/odoo/pull/152930 Part 2: https://github.com/odoo/odoo/pull/153018 Part 3: https://github.com/odoo/odoo/pull/153023 Part 4:…
## Pull Request HOOT (PRHOOT) - part 15.5 Part 1: https://github.com/odoo/odoo/pull/152930 Part 2: https://github.com/odoo/odoo/pull/153018 Part 3: https://github.com/odoo/odoo/pull/153023 Part 4: https://github.com/odoo/odoo/pull/153203 Part 5: https://github.com/odoo/odoo/pull/153425 Part 6: https://github.com/odoo/odoo/pull/153700 Part 7: https://github.com/odoo/odoo/pull/154054 Part 8: https://github.com/odoo/odoo/pull/154579 Part 9: https://github.com/odoo/odoo/pull/155073 Part 10: https://github.com/odoo/odoo/pull/155639 Part 11: https://github.com/odoo/odoo/pull/156255 / https://github.com/odoo/enterprise/pull/58135 Part 12: https://github.com/odoo/odoo/pull/156869 Part 13: https://github.com/odoo/odoo/pull/158384 / https://github.com/odoo/enterprise/pull/59019 Part 14: https://github.com/odoo/odoo/pull/158916 Part 15: https://github.com/odoo/odoo/pull/160292 / https://github.com/odoo/enterprise/pull/59971 This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
17 changes
Enhancements to existing features
Project sharing tests were updated to stay aligned with related changes in the community edition. This helps ensure sales timesheet features continue to be validated correctly after the shared wizard behavior changed.
Original PR description
This commit adapts the using of `project.share.wizard` wizard due to the changes made in the related PR in community. Community PR: odoo/odoo#165065
7 changes
Enhancements to existing features
This update adjusts the color of placeholder text in input fields to make it appear lighter and more distinct from regular text. Previously, placeholder text was too similar in color to actual user-entered text, which could cause confusion. The change improves the user experience by making it clearer which text is a placeholder versus actual content.
Original PR description
This PR aims to decrease a bit the contrast of placeholder textin order to avoid confusion with regular text. Prior to this PR, placeholder texts were using a gray value from the grayscale, which was very similar to the `$body-color` in some context. To fix that issue, the color of the placeholder has been reduced to make it lighter, even though it doesn't meet `3.5:1` contrast ratio. task-3686510 - requires https://github.com/odoo/odoo/pull/164510 Forward-Port-Of: odoo/enterprise#63111 Forward-Port-Of: odoo/enterprise#62029
This update makes translated messages more reliable by naming placeholders in text that contains multiple dynamic values. It helps translators reorder words naturally for different languages, reducing awkward or incorrect translations across affected Odoo Enterprise modules.
Original PR description
## The problem Translating text in a language sometimes involves reordering words. Positional arguments are always inserted in the same order, which order matches English syntax, but this isn't…
## The problem
Translating text in a language sometimes involves reordering words. Positional arguments are always inserted in the same order, which order matches English syntax, but this isn't necessarily right for every syntax of every language in the world.
Here's an eloquent example of the problem, taken from the GNU gettext documentation:
```c
printf(gettext("String '%s' has %d characters\n"), s, strlen(s));
```
which one could translate in German as follows:
```c
"%d Zeichen lang ist die Zeichenkette `%s'"
```
Even without knowing any of German, you could notice that the positions of `%d` and `%s` have been swapped; yet printf would still insert its arguments in the same order.
That's the reason why, whenever there is more than one “format specifier” (`%s`), you should always use keyworded arguments so that the translators can freely reorder the words without any problems.
## The fix
This pull request fixes the problem by naming providing a name to the placeholders of every call to gettext with more than two placeholders.
Part of task-3869533
Community: https://github.com/odoo/odoo/pull/166014Resolved issues and error corrections
Several localization and accounting EDI tests were updated to match the new invoice line behavior where product names are no longer automatically used as line names. This helps keep electronic invoicing, tax, and statutory reporting checks reliable after the product widget change.
Original PR description
*: account_avatax, account_saft, l10n_cl_edi_export, l10n_co_edi, l10n_it_reports, l10n_lu_reports, l10n_mx_edi, l10n_mx_xml_polizas, l10n_nl_reports --- This commit modifies tests to adapt to the new behavior of the invoice lines' name not using the product name anymore. --- task-3888602 Community PR: https://github.com/odoo/odoo/pull/152869
The workspace settings menu in Documents now displays with the correct spacing after a Bootstrap update caused the layout to look broken. This keeps the menu readable and easier to use for users managing document workspaces.
Original PR description
Steps to reproduce 1. Click on the cog wheel menu of a workspace 2. The menu padding is broken Reason: Bootstrap library updated. After this commit: There is no broken wheel menu of a workspace. Task:3892891
Miscellaneous changes
0 lines are still included in exported report when Hide lines at 0 is toggled Steps to reproduce: - Open a report, e.g. Balance Sheet (Accounting > Reporting > Balance Sheet) - In options, toggle 'Hide lines at 0' - Click in PDF to export a PDF version of the report - 0 lines are included in the PDF file When "Hide lines at 0" is toggled, lines at 0 are still included in the PDF/XLSX report, despite being hidden in the report view. This leads to a difference between what the user sees
Original PR description
0 lines are still included in exported report when Hide lines at 0 is toggled Steps to reproduce: - Open a report, e.g. Balance Sheet (Accounting > Reporting > Balance Sheet) - In options, toggle…
0 lines are still included in exported report when Hide lines at 0 is toggled Steps to reproduce: - Open a report, e.g. Balance Sheet (Accounting > Reporting > Balance Sheet) - In options, toggle 'Hide lines at 0' - Click in PDF to export a PDF version of the report - 0 lines are included in the PDF file When "Hide lines at 0" is toggled, lines at 0 are still included in the PDF/XLSX report, despite being hidden in the report view. This leads to a difference between what the user sees and what is printed. Another reason to hide lines at 0 from the printed report is that lines with Hide if Zero checked does impact the PDF. This means the two options (Hide lines at 0 and Hide if Zero) have similar impacts in the user view but different behavior in printed reports. This commit implements the function _filter_out_0_lines to remove lines at 0 from printed report if "Hide lines at 0" is toggled, and adds a test. task-3888290 Forward-Port-Of: odoo/enterprise#63061 Forward-Port-Of: odoo/enterprise#63000
Since the commit https://github.com/odoo/enterprise/pull/52348/commits/5c11c94b972d1993de4147d96fc3faaaaddc7c57 a test has been added that check the cloc result it stored on a ICP. But the result can be a bit different then expected during custom build if custom module are installed prior mail_enterprise. Solution: Check only the value of odoo/studio module that give the custom line in database that should be always empty during installation Forward-Port-Of: odoo/enterprise#63108 Forward-
Original PR description
Since the commit https://github.com/odoo/enterprise/pull/52348/commits/5c11c94b972d1993de4147d96fc3faaaaddc7c57 a test has been added that check the cloc result it stored on a ICP. But the result can be a bit different then expected during custom build if custom module are installed prior mail_enterprise. Solution: Check only the value of odoo/studio module that give the custom line in database that should be always empty during installation Forward-Port-Of: odoo/enterprise#63108 Forward-Port-Of: odoo/enterprise#62909
This was currently defined in `crm_enterprise` which made impossible to run QUnit tests dependent on this model in community. runbot-65889 https://github.com/odoo/odoo/pull/166475 Forward-Port-Of: odoo/enterprise#63056
Original PR description
This was currently defined in `crm_enterprise` which made impossible to run QUnit tests dependent on this model in community. runbot-65889 https://github.com/odoo/odoo/pull/166475 Forward-Port-Of: odoo/enterprise#63056
Before this commit: ============== When the delivery address is in India but the invoice address is outside India, Shiprocket will not consider the shipping address and mobile number from a different country. After this commit: ============== The correct phone/mobile number is provided for the delivery address. opw - 3841506 Forward-Port-Of: odoo/enterprise#61234
Original PR description
Before this commit: ============== When the delivery address is in India but the invoice address is outside India, Shiprocket will not consider the shipping address and mobile number from a different country. After this commit: ============== The correct phone/mobile number is provided for the delivery address. opw - 3841506 Forward-Port-Of: odoo/enterprise#61234
Access with User having Accounting permissions Open a posted invoice Click 'Reset to draft' Issue: Access Error will raise """ This operation is allowed for the following groups: - Payroll/Officer : Manage all contracts Contact your administrator to request access if necessary. """ Accounting user should be able to reset to draft without having payroll permissions opw-3932705 Forward-Port-Of: odoo/enterprise#62950
Original PR description
Access with User having Accounting permissions Open a posted invoice Click 'Reset to draft' Issue: Access Error will raise """ This operation is allowed for the following groups: - Payroll/Officer : Manage all contracts Contact your administrator to request access if necessary. """ Accounting user should be able to reset to draft without having payroll permissions opw-3932705 Forward-Port-Of: odoo/enterprise#62950
An error is raised when accessing customer statement from contact page in studio. ### Steps to reproduce: - Install Studio, Contact apps and the l10n_account_customer_statements module. - Open studio and go to Reports - When clicking on the Customer Statements report an error is raised ### Cause: Studio uses the partner res.partner(0,) to display the report in edit mode, but the method _get_report_values is always searching for the partner data to fill the report. The error is raised b
Original PR description
An error is raised when accessing customer statement from contact page in studio. ### Steps to reproduce: - Install Studio, Contact apps and the l10n_account_customer_statements module. - Open studio and go to Reports - When clicking on the Customer Statements report an error is raised ### Cause: Studio uses the partner res.partner(0,) to display the report in edit mode, but the method _get_report_values is always searching for the partner data to fill the report. The error is raised because res.partner(0,) does not reference any partner. ### Solution: Modify _get_report_values to search for partner data only if the partner id is different from 0. opw-3920298 Forward-Port-Of: odoo/enterprise#62891
Fixed typo for `cdfi` that not generates the section for bank accounts on the PDF for payment complement, and with this fix was improved the way to get the values from the dict, because not in all the cases are assigned all the values. https://github.com/odoo/enterprise/blob/17.0/l10n_mx_edi/models/account_move.py#L392 Forward-Port-Of: odoo/enterprise#62836
Original PR description
Fixed typo for `cdfi` that not generates the section for bank accounts on the PDF for payment complement, and with this fix was improved the way to get the values from the dict, because not in all the cases are assigned all the values. https://github.com/odoo/enterprise/blob/17.0/l10n_mx_edi/models/account_move.py#L392 Forward-Port-Of: odoo/enterprise#62836
`action_view_carryover_lines` calls account.report._get_date_bounds_info which is only defined in `account_reports`, and is itself only called from `account_reports`. It wouldn't have worked anyway for anyone who would have tried to call it without account_reports installed. So we take the liberty of moving it to account_reports in stable. See https://github.com/odoo/odoo/pull/155614#discussion_r1609626035 for context Forward-Port-Of: odoo/enterprise#63114 Forward-Port-Of: odoo/enterpr
Original PR description
`action_view_carryover_lines` calls account.report._get_date_bounds_info which is only defined in `account_reports`, and is itself only called from `account_reports`. It wouldn't have worked anyway for anyone who would have tried to call it without account_reports installed. So we take the liberty of moving it to account_reports in stable. See https://github.com/odoo/odoo/pull/155614#discussion_r1609626035 for context Forward-Port-Of: odoo/enterprise#63114 Forward-Port-Of: odoo/enterprise#63092
To reproduce the issue, on a runbot with the demo data: 1) Setup a prefix group threshold of 2 on the Partner Ledger 2) Open the Partner Ledger ==> The lines created for the prefix groups show "0.0" in the columns supposed to contain non-number values. Instead, these columns should contain empty values on those lines. The bug originates in the common helper called to generate the prefix group lines, so it does not only impact the Partner Ledger. We fix it and modify the test a little bi
Original PR description
To reproduce the issue, on a runbot with the demo data: 1) Setup a prefix group threshold of 2 on the Partner Ledger 2) Open the Partner Ledger ==> The lines created for the prefix groups show "0.0" in the columns supposed to contain non-number values. Instead, these columns should contain empty values on those lines. The bug originates in the common helper called to generate the prefix group lines, so it does not only impact the Partner Ledger. We fix it and modify the test a little bit to check that behavior as well. Forward-Port-Of: odoo/enterprise#63052 Forward-Port-Of: odoo/enterprise#62740
Steps to reproduce: - Create an expense - Add a product (with units) - Save - Add an attachement - Change the units Issue: The price unit will change to match the total Cause: We wanted to avoid using the _price_compute in case of the OCR Solution: We are making sure that the price unit is only recomputed when using the OCR community: https://github.com/odoo/odoo/pull/165352 opw-3869104 Forward-Port-Of: odoo/enterprise#62425
Original PR description
Steps to reproduce: - Create an expense - Add a product (with units) - Save - Add an attachement - Change the units Issue: The price unit will change to match the total Cause: We wanted to avoid using the _price_compute in case of the OCR Solution: We are making sure that the price unit is only recomputed when using the OCR community: https://github.com/odoo/odoo/pull/165352 opw-3869104 Forward-Port-Of: odoo/enterprise#62425
While filing GSTR-1, we encountered the following error: ``` [0]JSON validation failed due to - #: extraneous key [supeco] is not permitted ``` In this commit, we have resolved the error mentioned above. For various reasons, the government API has not yet implemented GSTR-1 tables 14 and 15 in production though they are available in the sandbox environment. As a solution, it is best not to include supeco in the JSON until the government API releases supeco into production. Forward-P
Original PR description
While filing GSTR-1, we encountered the following error: ``` [0]JSON validation failed due to - #: extraneous key [supeco] is not permitted ``` In this commit, we have resolved the error mentioned above. For various reasons, the government API has not yet implemented GSTR-1 tables 14 and 15 in production though they are available in the sandbox environment. As a solution, it is best not to include supeco in the JSON until the government API releases supeco into production. Forward-Port-Of: odoo/enterprise#62824
This PR aims to decrease a bit the contrast of placeholder textin order to avoid confusion with regular text. Prior to this PR, placeholder texts were using a gray value from the grayscale, which was very similar to the `$body-color` in some context. To fix that issue, the color of the placeholder has been reduced to make it lighter, even though it doesn't meet `3.5:1` contrast ratio. task-3686510 - requires https://github.com/odoo/odoo/pull/164510 Forward-Port-Of: odoo/enterprise#631
Original PR description
This PR aims to decrease a bit the contrast of placeholder textin order to avoid confusion with regular text. Prior to this PR, placeholder texts were using a gray value from the grayscale, which was very similar to the `$body-color` in some context. To fix that issue, the color of the placeholder has been reduced to make it lighter, even though it doesn't meet `3.5:1` contrast ratio. task-3686510 - requires https://github.com/odoo/odoo/pull/164510 Forward-Port-Of: odoo/enterprise#63111 Forward-Port-Of: odoo/enterprise#62029
Currently, when importing a CAMT file, the system fails to use `<AddtlNtryInf>` as a fallback for the payment reference. ### Steps to Reproduce 1. Install `account_bank_statement_import_camt`. 2. Import a CAMT file with a statement that includes `<TxDtls>` but no `<RmtInf>`, and has `<AddtlNtryInf>` defined. (You can use the one provided in the tests) **Expected Result:** The imported statement's payment reference should contain the value of `<AddtlNtryInf>`. **Actual Result:** The
Original PR description
Currently, when importing a CAMT file, the system fails to use `<AddtlNtryInf>` as a fallback for the payment reference. ### Steps to Reproduce 1. Install `account_bank_statement_import_camt`. 2. Import a CAMT file with a statement that includes `<TxDtls>` but no `<RmtInf>`, and has `<AddtlNtryInf>` defined. (You can use the one provided in the tests) **Expected Result:** The imported statement's payment reference should contain the value of `<AddtlNtryInf>`. **Actual Result:** The imported statement's payment reference contains `/` instead. ### Cause The system attempts to use `<AddtlNtryInf>` as a fallback for `payment_ref`. However, it looks in the wrong place. It searches inside `<TxDtls>`, whereas `<AddtlNtryInf>` is actually a child of `<Ntry>`. opw-3878785 Forward-Port-Of: odoo/enterprise#62703
This update improves how Odoo communicates with VoIP service providers by including the Odoo version number in the technical headers of VoIP calls. This helps providers better support and troubleshoot issues with different Odoo versions.
Original PR description
Include the version of Odoo in the UserAgent header of SIP requests so that the information is available to the provider. Task-3940569 Forward-Port-Of: odoo/enterprise#62970 Forward-Port-Of: odoo/enterprise#62879
Resolved issues and error corrections
Fixed a test in the mail module that was failing inconsistently when custom modules were installed before the mail enterprise module. The fix narrows the test to check only the Studio module's custom code metrics, which remain consistent across different installation scenarios. This ensures tests pass reliably regardless of what other custom modules are present.
Original PR description
Since the commit https://github.com/odoo/enterprise/pull/52348/commits/5c11c94b972d1993de4147d96fc3faaaaddc7c57 a test has been added that check the cloc result it stored on a ICP. But the result can be a bit different then expected during custom build if custom module are installed prior mail_enterprise. Solution: Check only the value of odoo/studio module that give the custom line in database that should be always empty during installation Forward-Port-Of: odoo/enterprise#63108 Forward-Port-Of: odoo/enterprise#62909
This fix enables the "Error amount too high" message in the Point of Sale sales management screen to be translated into different languages. Previously, this error message was hardcoded and could not be translated, limiting usability for non-English users. The fix adds the necessary translation wrapper to allow this message to appear in the user's preferred language.
Original PR description
In order for some text in the JavaScript code to be translatable, it must be wrapped in a call to _t. The title of a popup in the "sales management screen" missed this call to _t, preventing it from being translated. This commit fixes the problem by adding the missing call to _t. opw-3908751 Forward-Port-Of: odoo/odoo#165499 Forward-Port-Of: odoo/odoo#165337
This update adjusts the color of placeholder text in web forms to be lighter and more visually distinct from regular text. Previously, placeholder text used a gray color that was too similar to regular body text, causing potential confusion for users. The change makes placeholder text appear lighter to improve clarity and user experience.
Original PR description
This PR aims to decrease a bit the contrast of placeholder textin order to avoid confusion with regular text. Prior to this PR, placeholder texts were using a gray value from the grayscale, which was very similar to the `$body-color` in some context. To fix that issue, the color of the placeholder has been reduced to make it lighter, even though it doesn't meet `3.5:1` contrast ratio. task-3686510 - requires https://github.com/odoo/enterprise/pull/62029 Forward-Port-Of: odoo/odoo#166581 Forward-Port-Of: odoo/odoo#164510
Code cleanup and technical improvements
A function that displays carryover lines has been moved from the core accounting module to the account reports module, where it actually belongs. This fixes a dependency issue where the function was calling other functions that only exist in account reports, making it unusable without that module installed.
Original PR description
`action_view_carryover_lines` calls account.report._get_date_bounds_info which is only defined in `account_reports`, and is itself only called from `account_reports`. It wouldn't have worked anyway for anyone who would have tried to call it without account_reports installed. So we take the liberty of moving it to account_reports in stable. See https://github.com/odoo/odoo/pull/155614#discussion_r1609626035 for context Forward-Port-Of: odoo/enterprise#63114 Forward-Port-Of: odoo/enterprise#63092
A function that displays carryover lines has been moved from the core accounting module to the accounting reports module, where it actually belongs. This change improves code organization since the function only works when the reports module is installed and is only used there.
Original PR description
`action_view_carryover_lines` calls account.report._get_date_bounds_info which is only defined in `account_reports`, and is itself only called from `account_reports`. It wouldn't have worked anyway for anyone who would have tried to call it without account_reports installed. So we take the liberty of moving it to account_reports in stable. See https://github.com/odoo/odoo/pull/155614#discussion_r1609626035 for context Forward-Port-Of: odoo/odoo#166586 Forward-Port-Of: odoo/odoo#166545