Friday, August 23, 2024
32 changes · saas-17.2
Enhancements to existing features
This update improves Odoo's internal Hoot testing framework, making automated tests more accurate, easier to diagnose, and faster to use. It helps developers catch issues earlier and reduces the risk of unstable test results without changing business features for end users.
Original PR description
## Pull Request HOOT (PRHOOT) - part 22 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 22 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 Part 15.5: https://github.com/odoo/odoo/pull/166463 Part 16: https://github.com/odoo/odoo/pull/166311 Part 17: https://github.com/odoo/odoo/pull/168328 Part 18: https://github.com/odoo/odoo/pull/171004 / https://github.com/odoo/enterprise/pull/65657 Part 19: https://github.com/odoo/odoo/pull/171242 / https://github.com/odoo/enterprise/pull/65767 Part 20: https://github.com/odoo/odoo/pull/173332 / https://github.com/odoo/enterprise/pull/66895 Part 21: https://github.com/odoo/odoo/pull/174337 Enterprise: https://github.com/odoo/enterprise/pull/68721 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
Resolved issues and error corrections
This fix avoids trying to update barcode lookup website data before those records exist. It helps prevent installation failures when adding website sales after the barcode lookup module has already been installed.
Original PR description
This commit removes the 2 updates on data record created in product_barcodelokup module as they were introduced in stable version. Meaning having `product_barcodelokup` installed then fetch commit 50a4b00a7dde then installing `website_sale` will try to update records that doesn't exist yet. Sentry 5731062091
Miscellaneous changes
## Analysis Since a recent commit (https://github.com/odoo/enterprise/commit/25f72c0b716d5fdc15493b74375106e3d6f580fa), the operation_note is fetched independently from the other fields to avoid performance issues. This causes issues as, when computing data context (e.g. during `onChange`), we assume that all fields in data are available in config: ``` _computeDataContext() { ... const data = toRaw(this.data); for (const fieldName in data) { const value = data
Original PR description
## Analysis Since a recent commit (https://github.com/odoo/enterprise/commit/25f72c0b716d5fdc15493b74375106e3d6f580fa), the operation_note is fetched independently from the other fields to avoid…
## Analysis
Since a recent commit (https://github.com/odoo/enterprise/commit/25f72c0b716d5fdc15493b74375106e3d6f580fa), the operation_note is fetched independently from the other fields to avoid performance issues.
This causes issues as, when computing data context (e.g. during `onChange`), we assume that all fields in data are available in config:
```
_computeDataContext() {
...
const data = toRaw(this.data);
for (const fieldName in data) {
const value = data[fieldName];
const field = this.fields[fieldName]; // field == undefined
if (field.relatedPropertyField) { // traceback
continue;
}
...
}
```
## Steps to reproduce
- Create a product "TEST"
- Create a BoM For product "TEST", with a new product "TEST Component".
- Add 1 Operation OP1 (keep default value), set a description
- Add 1 step to OP1, with type "Register Production"
- Create MO for "TEST", Confirm, Plan,
- Start operation OP1
- On ShopFloor, go to MO, select workcenter, open step
- Update quantity: Error
## Solution
We make a way for manually fetched fields (most probably, all HTML fields which can contain base64 images) and add it to the fields to avoid them being undefined and causing tracebacks.
## References
opw-4103712
--
I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr)
Forward-Port-Of: odoo/enterprise#68497This update adjusts internal tests for the Gantt view so they correctly handle mobile touch interactions. It helps keep mobile drag-and-drop behavior reliably validated without changing customer-facing functionality.
Original PR description
## Pull Request HOOT (PRHOOT) - part 22 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 22 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 Part 15.5: https://github.com/odoo/odoo/pull/166463 Part 16: https://github.com/odoo/odoo/pull/166311 Part 17: https://github.com/odoo/odoo/pull/168328 Part 18: https://github.com/odoo/odoo/pull/171004 / https://github.com/odoo/enterprise/pull/65657 Part 19: https://github.com/odoo/odoo/pull/171242 / https://github.com/odoo/enterprise/pull/65767 Part 20: https://github.com/odoo/odoo/pull/173332 / https://github.com/odoo/enterprise/pull/66895 Part 21: https://github.com/odoo/odoo/pull/174337 Community: https://github.com/odoo/odoo/pull/176777 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
The task portal now avoids sending users to empty timesheet pages when they do not have permission to view any related timesheets. It also checks timesheets across all levels of subtasks, making the link behavior clearer and reducing confusion for limited-access users.
Original PR description
Currently, when a user has a limited access to timesheets, it is possible that he has access to a task, but that he has no access to the timesheets of its children task. This make a strange use case where the user clicks on the link to be redirected to a page without any timesheet. This fix aims to change that. Solution : change the link to the timesheets into a span if none of the timesheets are accessible by the current user. task - 3978484 version saas-17.2 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
If longpolling fails, it displays a fail popup with help messages. We added a `fallback` parameter allowing to prevent this popup from displaying if we want to fallback on other methods (e.g. websocket). Forward-Port-Of: odoo/enterprise#68719
Original PR description
If longpolling fails, it displays a fail popup with help messages. We added a `fallback` parameter allowing to prevent this popup from displaying if we want to fallback on other methods (e.g. websocket). Forward-Port-Of: odoo/enterprise#68719
Forward-Port-Of: odoo/enterprise#68704
Original PR description
Forward-Port-Of: odoo/enterprise#68704
Accounting > Configuration > Followup Levels Open the first level, enable 'Auto Execute' Delete the remaining follow up levels Create an invoice for a partner dated in the past with payment terms 'Immediate Payment' Run manually the cron 'Account Report Followup; Execute followup' Issue: partner will be processed by the cron, a warning will be logged but the partner next remainder date has not changed, so the next day the partner will be processed again. It is an issue when partner st
Original PR description
Accounting > Configuration > Followup Levels Open the first level, enable 'Auto Execute' Delete the remaining follow up levels Create an invoice for a partner dated in the past with payment terms 'Immediate Payment' Run manually the cron 'Account Report Followup; Execute followup' Issue: partner will be processed by the cron, a warning will be logged but the partner next remainder date has not changed, so the next day the partner will be processed again. It is an issue when partner starts to accumulate as all the partner with missing info will be processed daily without further notice This commit introduce the following mitigations for the issue: - Update the next remainder date even if no message has been sent - Limit the number of partner we process per run to 1000 - Add a message to the partner record in case the followup action failed opw-3935084 Forward-Port-Of: odoo/enterprise#68615 Forward-Port-Of: odoo/enterprise#66770
Add a new module that supports printing to the Philippine check format Task id # 3576570 Forward-Port-Of: odoo/enterprise#56117
Original PR description
Add a new module that supports printing to the Philippine check format Task id # 3576570 Forward-Port-Of: odoo/enterprise#56117
Currently, receipts are not take into account when generating the VAT Record books ### Steps to reproduce * install `l10n_es_reports` * switch to a Spanish company * enable sales (or purchase) receipts in the settings * create and confirm a sales receipt * open the generic tax report * select the dates for the receipt. * attempt to generate the VAT Record books You will be met with a traceback. ### Fix Include receipts and treat them as invoices. (confirmed with JCO) opw-
Original PR description
Currently, receipts are not take into account when generating the VAT Record books ### Steps to reproduce * install `l10n_es_reports` * switch to a Spanish company * enable sales (or purchase) receipts in the settings * create and confirm a sales receipt * open the generic tax report * select the dates for the receipt. * attempt to generate the VAT Record books You will be met with a traceback. ### Fix Include receipts and treat them as invoices. (confirmed with JCO) opw-4053187 Comunity PR: odoo/odoo#175002 Forward-Port-Of: odoo/enterprise#67621
If you were born after 2000 your insz number wouldn't be recognized as valid. Steps to reproduce: ------------------- * Install pos_blackbox_be module and HR module * Create an employee with a birth date set after 2000 * Generate an insz number for a person born after 2000 https://www.rsolution.be/rijksregister-nummer-generator.RSolution * Set the number on the employee and remove all `.` and `-` > Observation: When saving the insz wouldn't be recognized as valid Why the fix: ------
Original PR description
If you were born after 2000 your insz number wouldn't be recognized as valid. Steps to reproduce: ------------------- * Install pos_blackbox_be module and HR module * Create an employee with a birth date set after 2000 * Generate an insz number for a person born after 2000 https://www.rsolution.be/rijksregister-nummer-generator.RSolution * Set the number on the employee and remove all `.` and `-` > Observation: When saving the insz wouldn't be recognized as valid Why the fix: ------------ When trying to validate a insz number for a person born after 2000, the calculation is a bit different. You need to add a `2` before `partial_number` to make it work. Explanation can be found on wikipedia here: https://fr.wikipedia.org/wiki/Num%C3%A9ro_de_registre_national opw-4077545 Forward-Port-Of: odoo/enterprise#68723
**Steps to reproduce:** - Install Accounting and l10n_co - Switch to a Colombian company (e.g. CO Company) - Create a bill with a line having an IVA tax and a withholding tax: * IVA Compra 19% * RteIVA 15% sobre el 19% IVA - Post the bill - Create another bill with a line having only an IVA tax - Post the bill - Go to "Accounting / Reporting / Colombian Statements / Certificado de Retención en IVA" **Issue:** "Monto del Pago Sujeto Retención" column is incorrect. It takes into a
Original PR description
**Steps to reproduce:** - Install Accounting and l10n_co - Switch to a Colombian company (e.g. CO Company) - Create a bill with a line having an IVA tax and a withholding tax: * IVA Compra 19% *…
**Steps to reproduce:** - Install Accounting and l10n_co - Switch to a Colombian company (e.g. CO Company) - Create a bill with a line having an IVA tax and a withholding tax: * IVA Compra 19% * RteIVA 15% sobre el 19% IVA - Post the bill - Create another bill with a line having only an IVA tax - Post the bill - Go to "Accounting / Reporting / Colombian Statements / Certificado de Retención en IVA" **Issue:** "Monto del Pago Sujeto Retención" column is incorrect. It takes into account the tax amount from the IVA tax of both bills. As there is no withholding tax on the second bill, it should be excluded from the report. **Cause:** The report is checking the tax lines where the account is "2408%%" to compute the amount of this column. So every tax lines with from an IVA tax will be taken into account, even if there is no wihholding tax. **Solution:** Computing the correct amount by checking the account and the presence of a withholding tax is pretty complex. It would require to rely on the invoice lines instead of the tax lines to recompute the tax amounts because the amount of a specific tax is aggregated into a unique tax line (even if there are several invoice lines with different taxes combination) and there is no information about the tax repartition in the tax line. Recomputing all from the invoice lines would bad for the performance. As the withholding taxes are always 15% over VAT in Colombian localization, we can simply apply this formula to retrieve the amount subjected to withholding: [Monto del Pago Sujeto Retención = Retenido Consignado / 15%] opw-3989661 Forward-Port-Of: odoo/enterprise#68724 Forward-Port-Of: odoo/enterprise#68016
Updates the tax label and description translations in order to better fit the market. Task id # 4069669 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176258
Original PR description
Updates the tax label and description translations in order to better fit the market. Task id # 4069669 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176258
**Steps to reproduce:** - Create an empty db - Go to the configuration of the company - Set the country of the company to Bangladesh - Install Accounting **1st issue:** The localization module (i.e. l10n_bd) has not been installed. [Same issue with: l10n_bd, l10n_bf, l10n_bj, l10n_cd, l10n_cf, l10n_cg, l10n_ci, l10n_cm, l10n_cy, l10n_ga, l10n_gn, l10n_gq, l10n_gw, l10n_km, l10n_ml, l10n_mt, l10n_ne, l10n_rw, l10n_sn, l10n_td, l10n_tg, l10n_ug] - Go to Accounting settings - Select "
Original PR description
**Steps to reproduce:** - Create an empty db - Go to the configuration of the company - Set the country of the company to Bangladesh - Install Accounting **1st issue:** The localization module (i.e.…
**Steps to reproduce:**
- Create an empty db
- Go to the configuration of the company
- Set the country of the company to Bangladesh
- Install Accounting
**1st issue:**
The localization module (i.e. l10n_bd) has not been installed.
[Same issue with:
l10n_bd, l10n_bf, l10n_bj, l10n_cd, l10n_cf, l10n_cg, l10n_ci, l10n_cm, l10n_cy, l10n_ga, l10n_gn, l10n_gq, l10n_gw, l10n_km, l10n_ml, l10n_mt, l10n_ne, l10n_rw, l10n_sn, l10n_td, l10n_tg, l10n_ug]
- Go to Accounting settings
- Select "Bangladesh" as Fiscal Localization
- Save the settings
**2nd issue:**
A KeyError is raised:
File "/home/odoo/src/17_1/odoo/odoo/fields.py", line 1362, in compute_value
fields = records.pool.field_computed[self]
KeyError: 'account.asset.currency_id'
**Cause:**
**1st issue:**
"auto_install" is not present in the manifest file.
**2nd issue:**
When loading the chart template in "_load" method, "pool" attribute of "company" and "self" is not the same after the creation of a new registry. And [company = company.with_env(self.env)] does not update company.pool Therefore, when executing [self._pre_reload_data(company, template_data, data)], "self" and "company" are not on the same registry.
**Solution:**
**1st issue:**
Add 'auto_install': ['account'] in the manifest as it is done in others localization modules.
**2nd issue:**
Browse the company instead of using "with_env(self.env)" to update "company.pool".
opw-4119423
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#177254Before this PR, the `receive notifications from a channel` test was sometimes failing. This test waits for the channel to be registered before sending the notification. This flow has many async points: - bus service to worker to start it - bus service to worker to initialize it - worker to bus service to acknowledge the initialization - bus service to worker to add the channel The `waitUntilSubscribe` helper waits up to 500ms, but when runbot is heavily used, it can take a bit longer. Thi
Original PR description
Before this PR, the `receive notifications from a channel` test was sometimes failing. This test waits for the channel to be registered before sending the notification. This flow has many async points: - bus service to worker to start it - bus service to worker to initialize it - worker to bus service to acknowledge the initialization - bus service to worker to add the channel The `waitUntilSubscribe` helper waits up to 500ms, but when runbot is heavily used, it can take a bit longer. This PR increases the delay to ensure the flow can complete within the given time. runbot-75076 Forward-Port-Of: odoo/odoo#177530
The aim of this commit is to ensure we always have a company from which to pull values. Context: On odoo.com, we have only one website but when users buy something on our website, we create the so, the payment and the invoice with the company which is in the country of the user. This results in a situation in which the user initiating the question Before this commit: It was possible to not have a company there, leading to inconsistencies later on when relying on company to get some valu
Original PR description
The aim of this commit is to ensure we always have a company from which to pull values. Context: On odoo.com, we have only one website but when users buy something on our website, we create the so,…
The aim of this commit is to ensure we always have a company from which to pull values. Context: On odoo.com, we have only one website but when users buy something on our website, we create the so, the payment and the invoice with the company which is in the country of the user. This results in a situation in which the user initiating the question Before this commit: It was possible to not have a company there, leading to inconsistencies later on when relying on company to get some values like `tax_calculation_rounding_method`. For odoo.com, it resulted in a 0.01€ discrepancie between the sale order and its invoice. As the payment transaction was made based on the sale order amount, the invoice remained unpaid forcing the accountants to manually write off the difference. After this commit: There is always a default company provided ensuring taxes gets computed correctly and thus having sale order and invoice having the same amount. Special thanks to PMO for his HUGE help debugging this madness. task-id: None (issue spotted on odoo.com) Forward-Port-Of: odoo/odoo#177618
Currently, receipts are not take into account when generating the VAT Record books ### Steps to reproduce * install `l10n_es_reports` * switch to a Spanish company * enable sales (or purchase) receipts in the settings * create and confirm a sales receipt * open the generic tax report * select the dates for the receipt. * attempt to generate the VAT Record books You will be met with a traceback. ### Fix Include receipts and treat them as invoices. (confirmed with JCO) opw-
Original PR description
Currently, receipts are not take into account when generating the VAT Record books ### Steps to reproduce * install `l10n_es_reports` * switch to a Spanish company * enable sales (or purchase) receipts in the settings * create and confirm a sales receipt * open the generic tax report * select the dates for the receipt. * attempt to generate the VAT Record books You will be met with a traceback. ### Fix Include receipts and treat them as invoices. (confirmed with JCO) opw-4053187 Enterprise PR: odoo/enterprise#67621 Forward-Port-Of: odoo/odoo#175002
Following introduction of the new relational model in 8723f020c358, when an onchange is triggered from a field of a one2many, we were only sending parent's fields that are editable. This cause some issue when the user first trigger a change in the parent record that update some readonly fields (ex. computed fields), then trigger an onchange from one of the one2many fields; in that scenario the onchange will miss the updated readonly fields values from the parent; this can lead to wrong comp
Original PR description
Following introduction of the new relational model in 8723f020c358, when an onchange is triggered from a field of a one2many, we were only sending parent's fields that are editable. This cause some issue when the user first trigger a change in the parent record that update some readonly fields (ex. computed fields), then trigger an onchange from one of the one2many fields; in that scenario the onchange will miss the updated readonly fields values from the parent; this can lead to wrong computation of the onchange result. This commit send the values from parent readonly fields that have been modified (and with this align with server-side implementation behavior from `odoo.tests.form.Form`) opw-3941571 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177399
Set up email alias for Vendor Bill journal Send email with xls attachment to alias Bill is created Issue: No attachment is present This occurs because after https://github.com/odoo/odoo/commit/9b735f7597d75412a8ea6c4e541b05eb8849bd9c the system will not add binary attachments to the created bill The change was meant to filter out rogue images often present in emails but it is too restrictive so this commit add a second check with the mimetype of the parsed attachment in order to keep u
Original PR description
Set up email alias for Vendor Bill journal Send email with xls attachment to alias Bill is created Issue: No attachment is present This occurs because after https://github.com/odoo/odoo/commit/9b735f7597d75412a8ea6c4e541b05eb8849bd9c the system will not add binary attachments to the created bill The change was meant to filter out rogue images often present in emails but it is too restrictive so this commit add a second check with the mimetype of the parsed attachment in order to keep useful attachments opw-4092311 Forward-Port-Of: odoo/odoo#176004
1) Start creating a tax 2) Set the 'Tax Computation' to 'Group of taxes' 3) In 'Definition' tab, select 'Add a line', choose to create a new tax 4) Jumpt to 2 Issue: Nested group of taxes are not allowed When adding the child tax users cannot choose group of taxes, but we can't block creation of just a specific type of taxes so we need to check the type afterward opw-4060955 Forward-Port-Of: odoo/odoo#176359 Forward-Port-Of: odoo/odoo#173889
Original PR description
1) Start creating a tax 2) Set the 'Tax Computation' to 'Group of taxes' 3) In 'Definition' tab, select 'Add a line', choose to create a new tax 4) Jumpt to 2 Issue: Nested group of taxes are not allowed When adding the child tax users cannot choose group of taxes, but we can't block creation of just a specific type of taxes so we need to check the type afterward opw-4060955 Forward-Port-Of: odoo/odoo#176359 Forward-Port-Of: odoo/odoo#173889
This PR addresses issues with the custom amount selection on the `/donation/pay` page, which has been present since version 15.0. Users have experienced confusion about the actual donation amount due to the following bugs: **Bug 1:** Multiple amounts could be selected simultaneously, affecting versions 17+. **Bug 2:** The last selected amount was not the actual amount donated, affecting all versions from 15 onwards. **Fixes:** - This PR fixes Bug 2 in version 15.0, ensuring the correct
Original PR description
This PR addresses issues with the custom amount selection on the `/donation/pay` page, which has been present since version 15.0. Users have experienced confusion about the actual donation amount due to the following bugs: **Bug 1:** Multiple amounts could be selected simultaneously, affecting versions 17+. **Bug 2:** The last selected amount was not the actual amount donated, affecting all versions from 15 onwards. **Fixes:** - This PR fixes Bug 2 in version 15.0, ensuring the correct amount is selected and donated. - During the forward-port to version 17.0, we will also address Bug 1. The fix in version 17.0 will involve changes to the `payment_form.js` file, as the relevant file is no longer in use. The new solution will be cleaner and will not rely on `.o_wpayment_fee_impact`. task-4115678 Forward-Port-Of: odoo/odoo#177270 Forward-Port-Of: odoo/odoo#176722
FixImp, I often add such url assertions with bugfixes, I wanna use this new function with them Testing that we are correctly redirected to a specific URL is something recurrent in both the http framework and website. There are various competiting ways to achieve this. In this work we propose a single go-to function that (1) takes care of sanitizing both URLs to deal with missing scheme/host and (2) ouput a nice assertion message when the urls are different. It uses urllib3 because it pa
Original PR description
FixImp, I often add such url assertions with bugfixes, I wanna use this new function with them Testing that we are correctly redirected to a specific URL is something recurrent in both the http framework and website. There are various competiting ways to achieve this. In this work we propose a single go-to function that (1) takes care of sanitizing both URLs to deal with missing scheme/host and (2) ouput a nice assertion message when the urls are different. It uses urllib3 because it parses "example.com" as `netloc="example.com"` instead of urllib that parses it as `path="example.com"`. 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#177005 Forward-Port-Of: odoo/odoo#176763
Refactoring method _check_peppol_endpoint_number and _sanitize_peppol_endpoint. Added sanitization for current supported EAS. This refactoring will make it easier to add support for more EAS. Refactoring to solve issues with wrong handling of Peppol ID and make it easier to add better support for more EAS without large modifications. This will also make the code easier to support in the future. Original Discussion: https://github.com/odoo/odoo/pull/176109#issuecomment-2286587053 Forward
Original PR description
Refactoring method _check_peppol_endpoint_number and _sanitize_peppol_endpoint. Added sanitization for current supported EAS. This refactoring will make it easier to add support for more EAS. Refactoring to solve issues with wrong handling of Peppol ID and make it easier to add better support for more EAS without large modifications. This will also make the code easier to support in the future. Original Discussion: https://github.com/odoo/odoo/pull/176109#issuecomment-2286587053 Forward-Port-Of: odoo/odoo#176651
Problem --------- With commit c1ea29ea79ad074aae750d26496fc6ce22cffb54, we fixed the following problem: when reversing an invoice, the current company is used as recipient bank and not the customer's one. However, that fix did only took into concideration reversing invoices and not bills. This commit is here to fix that. When reversing a BILL (in_invoice), we use the company's bank. When reversing an INVOICE (out_invoice), we use the commercial partner's bank. opw-4035448 --- I
Original PR description
Problem --------- With commit c1ea29ea79ad074aae750d26496fc6ce22cffb54, we fixed the following problem: when reversing an invoice, the current company is used as recipient bank and not the customer's one. However, that fix did only took into concideration reversing invoices and not bills. This commit is here to fix that. When reversing a BILL (in_invoice), we use the company's bank. When reversing an INVOICE (out_invoice), we use the commercial partner's bank. opw-4035448 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177023
### Steps to reproduce: - Install Inventory module - Create a move from any operation - Save this move and keep the reference > Change the operation type and save again - Navigate to Moves History - Search for the move with the old reference ### Current behavior before PR: The move will be shown in the moves history with the old reference. This is happening because when changing the opertaion type it doesn't trigger the compute of the reference. https://github.com/odoo/odoo/blob/17
Original PR description
### Steps to reproduce: - Install Inventory module - Create a move from any operation - Save this move and keep the reference > Change the operation type and save again - Navigate to Moves History - Search for the move with the old reference ### Current behavior before PR: The move will be shown in the moves history with the old reference. This is happening because when changing the opertaion type it doesn't trigger the compute of the reference. https://github.com/odoo/odoo/blob/17.0/addons/stock/models/stock_move.py#L265 ### Desired behavior after PR is merged: We added the picking_id.name as a dependant field for the reference so when it is changed the computation method of the reference will be triggered to update the reference. opw-4062591 Forward-Port-Of: odoo/odoo#174398
When having a lot of forum posts, the pager can display up to 10 pages, because the specified scope is the set to the same value as the number of posts per page, which is 10. This causes layout issues in mobile view in that case, because the pager overflows from the page. This commit fixes that by setting the scope to 5 instead (like the Event pager), which is just enough to not overflow. opw-4050389 Forward-Port-Of: odoo/odoo#177436 Forward-Port-Of: odoo/odoo#177207
Original PR description
When having a lot of forum posts, the pager can display up to 10 pages, because the specified scope is the set to the same value as the number of posts per page, which is 10. This causes layout issues in mobile view in that case, because the pager overflows from the page. This commit fixes that by setting the scope to 5 instead (like the Event pager), which is just enough to not overflow. opw-4050389 Forward-Port-Of: odoo/odoo#177436 Forward-Port-Of: odoo/odoo#177207
From most openpyxl resources it is generally recommended to instantiate it as `read_only=True` or `write_only=True` in order to leverage lazy modes which do not need to eagerly load the entire file in memory. However this causes memory exhaustion issues in Odoo workers, with file preview / imports failing: apparently we have managed to generate the `res_partner.xlsx` sample file in such a way that `load_workbook(read_only=True)` is incapable of finding the end of the file, so it thinks the fi
Original PR description
From most openpyxl resources it is generally recommended to instantiate it as `read_only=True` or `write_only=True` in order to leverage lazy modes which do not need to eagerly load the entire file…
From most openpyxl resources it is generally recommended to instantiate it as `read_only=True` or `write_only=True` in order to leverage lazy modes which do not need to eagerly load the entire file in memory.
However this causes memory exhaustion issues in Odoo workers, with file preview / imports failing: apparently we have managed to generate the `res_partner.xlsx` sample file in such a way that `load_workbook(read_only=True)` is incapable of finding the end of the file, so it thinks the file goes up to the limit for the format of 1048576 rows:
$ python -c 'import openpyxl; w = openpyxl.load_workbook("odoo/addons/base/static/xls/res_partner.xlsx", data_only=True, read_only=True); print(sum(1 for _ in w.worksheets[0]))'
1048576
even though the file only has 4 rows (including the header).
This means any client which uses this file as basis to create their own export (or a method generating similarly odd / corrupted files) requires parsing on the order of 20~30 million cells to try and import the file, even though in reality they might only have a few dozens or hundreds.
As a result the import *attempt* takes several minutes (4~5 locally, maybe a bit less on beefy server) and ~1.7GB memory, and thus routinely fails if the worker has any sort of existing pressure (e.g. well filled caches) as it hits the hard memory limit (2.5G by default).
Using the "less efficient" standard mode, the ingestion takes ~1.4s and 14.5MB memory. Which is still a far cry less efficient than xlrd.xlsx was (~0.00 seconds and 120k) but at least somewhat reasonable...
The issue has been reported upstream at https://foss.heptapod.net/openpyxl/openpyxl/-/issues/2221
Forward-Port-Of: odoo/odoo#177586Add text editor write mode aliases. Forward-Port-Of: odoo/odoo#176974
Original PR description
Add text editor write mode aliases. Forward-Port-Of: odoo/odoo#176974
# Description With the upgrade to Chart.js version 4.3, the configuration for setting legend label colors has changed. The `fontColor` key is now deprecated, and the `color` key must be used instead. This update was previously overlooked in the Odoo chart plugin. This commit resolves the issue by updating the Odoo chart plugin to correctly use the color key for setting legend label colors. Task: [4111089](https://www.odoo.com/odoo/project/2328/tasks/4111089) --- I confirm I ha
Original PR description
# Description With the upgrade to Chart.js version 4.3, the configuration for setting legend label colors has changed. The `fontColor` key is now deprecated, and the `color` key must be used instead. This update was previously overlooked in the Odoo chart plugin. This commit resolves the issue by updating the Odoo chart plugin to correctly use the color key for setting legend label colors. Task: [4111089](https://www.odoo.com/odoo/project/2328/tasks/4111089) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177420
Example of steps: - install `inventory` - Open a transfer/receipts - add a product - validate it - click on return - there is a modal with the product - double click quickly on remove button - click return - traceback ``` psycopg2.errors.InvalidTextRepresentation: invalid input syntax for type integer: "virtual_12" LINE 1: ...ETE FROM "stock_return_picking_line" WHERE id IN ('virtual_1...
Original PR description
Example of steps: - install `inventory` - Open a transfer/receipts - add a product - validate it - click on return - there is a modal with the product - double click quickly on remove button - click…
Example of steps:
- install `inventory`
- Open a transfer/receipts
- add a product
- validate it
- click on return
- there is a modal with the product
- double click quickly on remove button
- click return
- traceback
```
psycopg2.errors.InvalidTextRepresentation: invalid input syntax for type integer: "virtual_12"
LINE 1: ...ETE FROM "stock_return_picking_line" WHERE id IN ('virtual_1...
^
```
When this modal is opened, a `one2many` is built with “virtual” records,
which are the products selected in the transfer.
These records are virtual because we don't know which ones the customer
will keep - we'll only know for sure when he clicks on “Return”.
So, when this o2m is loaded, the setup of the Record class populates it.
A first call to the `_applyCommands` function is made with a command to
create a record (product) (command 0/CREATE).
Once the o2m has been loaded, the customer (who quickly clicks to remove
several products) ends up at some point double-clicking on the remove
button of the same product will trigger two consecutive calls to `_applyCommands`.
The first call (which is the correct call)
will have the command: `[2, “virtual_12”]` which is a `DELETE`.
But as we've already asked to create the same “virtual_12” record,
we are here:
https://github.com/odoo/odoo/blob/7caddbb653aa8235725b48ff9f28d6119fdc3567/addons/web/static/src/model/relational_model/static_list.js#L580-L585
Here, given that we have a delete `virtual_12` command and that just before
the setup we asked to create `virtual_12`, this condition will just remove
the command that creates `virtual_12` to simplify the operation without
creating a `DELETE` command.
So instead of creating it and then deleting it, we just don't create it.
The problem arises with the second click, which triggers exactly the same
call to `_applyCommands`, asking to delete `virtual_12`.
As this time we don't have any more “record creation” pending, we'll
enter here
https://github.com/odoo/odoo/blob/7caddbb653aa8235725b48ff9f28d6119fdc3567/addons/web/static/src/model/relational_model/static_list.js#L583-L585
The second click will ask you to delete a record that never existed in
the `web_save`... so that's what the python server don't like!
To correct the problem, I apply a variable to the button in the dom,
which I set to true when the first click occurs, and which I check on
the second click to ignore it.
opw-[4043992](https://www.odoo.com/web#id=4043992&view_type=form&model=project.task)
Forward-Port-Of: odoo/odoo#173481Some spelling mistakes were forgotten in a previous pull request that meant to add constraints on carryover See https://github.com/odoo/odoo/pull/177064#pullrequestreview-2248102992 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177332
Original PR description
Some spelling mistakes were forgotten in a previous pull request that meant to add constraints on carryover See https://github.com/odoo/odoo/pull/177064#pullrequestreview-2248102992 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177332
The "Images Subtitles" and the "Thumbnails" mega menu templates do not look good in mobile view, depending on the size of the text written in them. Indeed, under some breakpoints, the classes force the elements to be next to each to other, to have two elements by line. So if a big word is contained in the left one, which is not rare in the German language for example, the text may overflow to the right one and overlap with it. This commit fixes this issue by adding more freedom to these mega
Original PR description
The "Images Subtitles" and the "Thumbnails" mega menu templates do not look good in mobile view, depending on the size of the text written in them. Indeed, under some breakpoints, the classes force…
The "Images Subtitles" and the "Thumbnails" mega menu templates do not look good in mobile view, depending on the size of the text written in them. Indeed, under some breakpoints, the classes force the elements to be next to each to other, to have two elements by line. So if a big word is contained in the left one, which is not rare in the German language for example, the text may overflow to the right one and overlap with it. This commit fixes this issue by adding more freedom to these mega menu templates at the problematic breakpoints, so they can be more responsive with their content, while still looking good. Step to reproduce: - In the menu editor, add a mega menu. - In edit mode, click on the mega menu. - Select the "Images Subtitles" or the "Thumbnails" template. - As a first element, write the following title: "Foto- und Fine Art Großformatdrucker". - Save and resize down the screen until it toggles the mobile view. - Open the mega menu and continue to resize down. => At some point, near the "SM" breakpoint, you will notice that the text becomes too big and overlaps the right element. opw-4096112 Forward-Port-Of: odoo/odoo#177103