Monday, January 20, 2025
53 changes
12 changes
Miscellaneous changes
**Steps to reproduce:** - Configure `Analytic Accounting` via `Accounting` module's settings; - Go to `Analytic Plans` through `Accounting / Configuration / Analytic Accounting`: - Select any record and change its name for a really long one;  - Go to `Expenses` app: - Select any expense in the list; - Open the `Analytic Distribution` widget. ___ **
Original PR description
**Steps to reproduce:** - Configure `Analytic Accounting` via `Accounting` module's settings; - Go to `Analytic Plans` through `Accounting / Configuration / Analytic Accounting`: - Select any record…
**Steps to reproduce:**
- Configure `Analytic Accounting` via `Accounting` module's settings;
- Go to `Analytic Plans` through `Accounting / Configuration / Analytic Accounting`:
- Select any record and change its name for a really long one;

- Go to `Expenses` app:
- Select any expense in the list;
- Open the `Analytic Distribution` widget.
___
**Issue:**
Long `Analytic Plans` names are wrapped and may lead to unreadable texts.

*(from the ticket - Odoo 17)*

___
**Expected:**
A smooth UI should display `Analytic Plans` as when accessed through an invoice line from `Accounting` app.

___
**Cause:**
The `Analytic Distribution` widget style of the invoice view inherits from the list renderer, forcing a `nowrap` style while the expense view of the same widget does not.
___
**Fix:**
Force a `nowrap` style for that specific widget.

___
opw-4357324
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#192203**Problem**: When `lot['lot_record'].product_id.valid_ean` is `False`, the `final_barcode` variable retains the value from the previous iteration. This leads to incorrect concatenation with the current `lot['name']` when `lot['lot_record'].product_id.tracking == 'lot'`. **Solution**: Reset the `final_barcode` variable at the start of each iteration. **Steps to Reproduce**: 1. Go to Inventory > Settings and enable "Print GS1 Barcodes for Lots & Serial Numbers". 2. Navigate to Inventory
Original PR description
**Problem**: When `lot['lot_record'].product_id.valid_ean` is `False`, the `final_barcode` variable retains the value from the previous iteration. This leads to incorrect concatenation with the current `lot['name']` when `lot['lot_record'].product_id.tracking == 'lot'`. **Solution**: Reset the `final_barcode` variable at the start of each iteration. **Steps to Reproduce**: 1. Go to Inventory > Settings and enable "Print GS1 Barcodes for Lots & Serial Numbers". 2. Navigate to Inventory > Products > Lots/Serial Numbers. 3. Select all records and click Print > Lot/Serial Number (ZPL). 4. Observe that some barcodes incorrectly include the previous barcode as a prefix. opw-4437745 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193519 Forward-Port-Of: odoo/odoo#192651
**Problem**: Enabling the addition of videos from Studio is not supported. This option should be removed. **Steps to Reproduce**: 1. In Studio, focus on any HTML field. 2. Under "Properties," there should be no "videos" option. opw-4405801 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191183
Original PR description
**Problem**: Enabling the addition of videos from Studio is not supported. This option should be removed. **Steps to Reproduce**: 1. In Studio, focus on any HTML field. 2. Under "Properties," there should be no "videos" option. opw-4405801 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191183
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#193752
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 Forward-Port-Of: odoo/odoo#193752
Steps: - Install the hr_holiday module - Configure Time Off Type with validation set to `Approved by Time Off Officer` or `Both` - Create a Time Off request without setting a Time Off Officer. --- Description of the issue/feature this PR addresses: When the validation type is set to `hr` or `both` and no Time Off Officer is configured, an activity is incorrectly generated upon creating a Time Off request. --- Fix: This PR resolves the issue by ensuring the responsible user is s
Original PR description
Steps: - Install the hr_holiday module - Configure Time Off Type with validation set to `Approved by Time Off Officer` or `Both` - Create a Time Off request without setting a Time Off Officer. --- Description of the issue/feature this PR addresses: When the validation type is set to `hr` or `both` and no Time Off Officer is configured, an activity is incorrectly generated upon creating a Time Off request. --- Fix: This PR resolves the issue by ensuring the responsible user is set to empty when validation is `hr` or `Both` and no Time Off Officer is configured. task-4351688 Forward-Port-Of: odoo/odoo#190193
`accounting_supplier_party` was never sent right from IAP, it was always 'None'. So, we could never log it. But the information was in fact always useless. This information is already in the UBL file. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192740
Original PR description
`accounting_supplier_party` was never sent right from IAP, it was always 'None'. So, we could never log it. But the information was in fact always useless. This information is already in the UBL file. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192740
'TestQwebFieldContact' used a demo partner to work, but we want to test independent of demo data. Forward-Port-Of: odoo/odoo#193716
Original PR description
'TestQwebFieldContact' used a demo partner to work, but we want to test independent of demo data. Forward-Port-Of: odoo/odoo#193716
Backporting from saas-17.3 odoo/odoo#137572 because of tickets, see opws below. The OpenSSL call started not working after `cryptography==42.0.8` \--- Some of the invoices (i.e. those from Servizio Elettrico Nazionale, the ex-monopoly-of-energy company) have custom signatures that rely on an old OpenSSL implementation that breaks the current one that sees them as malformed, so we cannot read those files. Also, we couldn't find an alternative way to use OpenSSL to just get the same res
Original PR description
Backporting from saas-17.3 odoo/odoo#137572 because of tickets, see opws below. The OpenSSL call started not working after `cryptography==42.0.8` \--- Some of the invoices (i.e. those from Servizio…
Backporting from saas-17.3 odoo/odoo#137572 because of tickets, see opws below. The OpenSSL call started not working after `cryptography==42.0.8` \--- Some of the invoices (i.e. those from Servizio Elettrico Nazionale, the ex-monopoly-of-energy company) have custom signatures that rely on an old OpenSSL implementation that breaks the current one that sees them as malformed, so we cannot read those files. Also, we couldn't find an alternative way to use OpenSSL to just get the same result without getting the error. A new fallback method has been added that reads the ASN1 file structure and takes the encoded pkcs7-data tag content out of it, regardless of the signature. Being a non-optimized pure Python implementation, it takes about 2x the time than the regular method, so it's better used as a fallback. We didn't use an existing library not to further pollute the dependencies space. \--- opw-4471459 opw-4437288 opw-4417875 Forward-Port-Of: odoo/odoo#194211 Forward-Port-Of: odoo/odoo#193950
This PR addresses the layout issue in the sidebar of the portal, where a preview of the customer's invoice is displayed. Before this PR, users encountered a broken layout for large invoice amounts, making it difficult to read the total. This issue is resolved in this PR by adding a rules for the `h2` and `span` fields ensuring proper wrapping for better readability. Steps to reproduce: - Login as admin. - Go to Website app. - Navigate to "My account" at my/home url. - Click on "
Original PR description
This PR addresses the layout issue in the sidebar of the portal, where a preview of the customer's invoice is displayed. Before this PR, users encountered a broken layout for large invoice amounts, making it difficult to read the total. This issue is resolved in this PR by adding a rules for the `h2` and `span` fields ensuring proper wrapping for better readability. Steps to reproduce: - Login as admin. - Go to Website app. - Navigate to "My account" at my/home url. - Click on "My invoices" or navigate to my/invoices url. - Click on one invoice in order to see its preview. - Via the browser tools, edit the amount of on the left sidebar and insert a very big number. task-4435472 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192769
@qrtl ------------------------------- 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/odoo#194087
Original PR description
@qrtl ------------------------------- 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/odoo#194087
### Steps to reproduce: - In Accounting create a new tax like this: -Tax computation: percentage of price tax included -Amount: 100% -Included in Price: Ticked - Create a new Customer Invoice in another currency - Use the 100% tax - Go in the tab "Journal Entries" - The amounts were not converted ### Cause: The rate is calculated like this : `rate = line.amount_currency / line.balance if line.balance else 1` But with this specific tax `amount_currency` and `balance` are 0 so the rate de
Original PR description
### Steps to reproduce: - In Accounting create a new tax like this: -Tax computation: percentage of price tax included -Amount: 100% -Included in Price: Ticked - Create a new Customer Invoice in another currency - Use the 100% tax - Go in the tab "Journal Entries" - The amounts were not converted ### Cause: The rate is calculated like this : `rate = line.amount_currency / line.balance if line.balance else 1` But with this specific tax `amount_currency` and `balance` are 0 so the rate defaults to 1 thus not converting. ### Solution: Fallback on the rate of the line. opw-4443522 Forward-Port-Of: odoo/odoo#193593
Before this commit, the module_loader was showing error by empty the DOM and then adding his element with the errors. The issue is, if you have an error because of custom script or after an upgrade, then you were lockout because the DOM with empty and you cannot go fix the script. After this commit, a shorter message will be shown in the bottom-left of the screen. This message will invite the user to check the devtool to have more details about the error. --- I confirm I have signed the
Original PR description
Before this commit, the module_loader was showing error by empty the DOM and then adding his element with the errors. The issue is, if you have an error because of custom script or after an upgrade, then you were lockout because the DOM with empty and you cannot go fix the script. After this commit, a shorter message will be shown in the bottom-left of the screen. This message will invite the user to check the devtool to have more details about the error. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193912
13 changes
Miscellaneous changes
In the document layout configurator, the paper format A4 would not be there if the module l10n_be_hr_payroll is installed. This is because in Belgium, some reports need A4 but in the configurator, we only get paperformat not linked to any report. The solution is to remove the domain for this field in the configurator. Since there will be more paper formats, I renamed the newly created formats in the Belgian payroll to differentiate them. Forward-Port-Of: odoo/enterprise#71649
Original PR description
In the document layout configurator, the paper format A4 would not be there if the module l10n_be_hr_payroll is installed. This is because in Belgium, some reports need A4 but in the configurator, we only get paperformat not linked to any report. The solution is to remove the domain for this field in the configurator. Since there will be more paper formats, I renamed the newly created formats in the Belgian payroll to differentiate them. Forward-Port-Of: odoo/enterprise#71649
Steps: - Install the hr_payroll module - Open the payslip form view - click on print --- Description of the issue/feature this PR addresses: When the schedule pay on a contract is set to anything other than `Monthly` (e.g., bi-weekly), the PDF report incorrectly displays `Monthly`. This happens because the report only considers the wage type (monthly or hourly) and does not take the schedule pay into account. --- Fix: This PR addresses the issue by including the schedule pay type
Original PR description
Steps: - Install the hr_payroll module - Open the payslip form view - click on print --- Description of the issue/feature this PR addresses: When the schedule pay on a contract is set to anything other than `Monthly` (e.g., bi-weekly), the PDF report incorrectly displays `Monthly`. This happens because the report only considers the wage type (monthly or hourly) and does not take the schedule pay into account. --- Fix: This PR addresses the issue by including the schedule pay type in the PDF report when the wage type is set to `Monthly`. task-4332531 Forward-Port-Of: odoo/enterprise#75342
Steps to reproduce: - install Documents - create a new spreadsheet - hit the Share button - change the sharing settings to "Anyone with the link: Viewer / Musty have the link to access" - open the sharing link in an incognito window - hit the download button => 404 not found A public user cannot convert a spreadsheet to an excel file and downlaod it because a route needs to be called to create the excel file. This route is currently not allowed for public users. For frozen sprea
Original PR description
Steps to reproduce: - install Documents - create a new spreadsheet - hit the Share button - change the sharing settings to "Anyone with the link: Viewer / Musty have the link to access" - open the sharing link in an incognito window - hit the download button => 404 not found A public user cannot convert a spreadsheet to an excel file and downlaod it because a route needs to be called to create the excel file. This route is currently not allowed for public users. For frozen spreadsheet, we generate the excel file before-hand (when the internal user shares the spreadsheet). For a regular "live" share though, we cannot pre-generate the excel file since the spreadsheet continues to live and evolve. The `spreadsheet` module needs to be updated for this bug fix to take effect. (otherwise the download button won't do anything, which is not worse than facing a 404 response) See also community PR. Task: 4440241 opw: 4417519 Forward-Port-Of: odoo/enterprise#76460
… technical In Odoo 18 > Benchmark dashboard does not show the correct balance per account type when the language is not English. The problem is we have a =_t(value) function that translate the technical name (C30:C47) opw-4484934 Task: 4484934 Forward-Port-Of: odoo/enterprise#77163
Original PR description
… technical In Odoo 18 > Benchmark dashboard does not show the correct balance per account type when the language is not English. The problem is we have a =_t(value) function that translate the technical name (C30:C47) opw-4484934 Task: 4484934 Forward-Port-Of: odoo/enterprise#77163
When validating the payment CFDI in multicurrency scenario (invoice in USD, payment in MXN), we should provide the official convertion rate in the equivalenciaDR xml attribute. However, this is not always possible due to rounding: PACs with lower error tolerance (Quadrum) will not validate the payment Steps to reproduce: - With an MX company setup - Set the following rates for USD - Date 1: 0.049905678268 - Date 2: 0.049073733284 - Create an invoice in date1 of 6368.40 USD (5490.00 w
Original PR description
When validating the payment CFDI in multicurrency scenario (invoice in USD, payment in MXN), we should provide the official convertion rate in the equivalenciaDR xml attribute. However, this is not…
When validating the payment CFDI in multicurrency scenario (invoice in USD, payment in MXN), we should provide the official convertion rate in the equivalenciaDR xml attribute. However, this is not always possible due to rounding: PACs with lower error tolerance (Quadrum) will not validate the payment Steps to reproduce: - With an MX company setup - Set the following rates for USD - Date 1: 0.049905678268 - Date 2: 0.049073733284 - Create an invoice in date1 of 6368.40 USD (5490.00 with 16% tax) - Register a full payment in date 2 in company currency (129772.07 MXN) Issue: Payment CFDI will not validate when using Quadrum PAC with error ``` Code : CRP20268 Message : El campo BaseP que corresponde a Traslado, no es igual a la suma de los importes de las bases registrados en los documentos relacionados donde el impuesto del documento relacionado sea igual al campo ImpuestoP de este elemento y la TasaOCuotaDR del documento relacionado sea igual al campo TasaOCuotaP de este elemento. ``` This occurs because when computing cfdi values we take the invoice (rounded) amounts and recompute the amount in mxn using the official currency rate. While doing so, due to rounding, we accumulate imprecision, the final computation might be off by a cent or two and PACs with a lower error tolerance (Quadrum) will not be able to validate the cfdi. A solution is to internally use the computed rate, while we provide the official currency rate in the xml opw-4357985 Forward-Port-Of: odoo/enterprise#76987 Forward-Port-Of: odoo/enterprise#76333
Fix preparation wrong variable name. `table_name` -> `table.table_number` Forward-Port-Of: odoo/enterprise#77276
Original PR description
Fix preparation wrong variable name. `table_name` -> `table.table_number` Forward-Port-Of: odoo/enterprise#77276
Enterprise counter-part. https://github.com/odoo/odoo/pull/187799 Forward-Port-Of: odoo/enterprise#77037 Forward-Port-Of: odoo/enterprise#74167
Original PR description
Enterprise counter-part. https://github.com/odoo/odoo/pull/187799 Forward-Port-Of: odoo/enterprise#77037 Forward-Port-Of: odoo/enterprise#74167
- Install `web_studio` and `l10n_ke_edi_oscu` - Open the report editor from anywhere - Search for report_invoice - Open it - Traceback This is caused by the div inside the table, this is incorrect in HTML See https://html.spec.whatwg.org/multipage/tables.html#the-table-element replace with a tr/td opw-4369019 Forward-Port-Of: odoo/enterprise#77132
Original PR description
- Install `web_studio` and `l10n_ke_edi_oscu`
- Open the report editor from anywhere
- Search for report_invoice
- Open it
- Traceback
This is caused by the div inside the table, this is incorrect in HTML
See https://html.spec.whatwg.org/multipage/tables.html#the-table-element
replace with a tr/td
opw-4369019
Forward-Port-Of: odoo/enterprise#77132The transfer form view contains two list views that were poorly displayed. The two were shrunk to half the available space. This is due to the fact that a group is by default two divs in a row each expecting one element, usually the label and the field value. However, only the value is to be displayed in our case. Hence, why the list only take up half of the space made avalailable by the group. To solve this, we can simply force the number of columns taken by the list to 2. task-4481314
Original PR description
The transfer form view contains two list views that were poorly displayed. The two were shrunk to half the available space. This is due to the fact that a group is by default two divs in a row each expecting one element, usually the label and the field value. However, only the value is to be displayed in our case. Hence, why the list only take up half of the space made avalailable by the group. To solve this, we can simply force the number of columns taken by the list to 2. task-4481314 Forward-Port-Of: odoo/enterprise#77346
In this PR: - Refactored error handling for better clarity and organization. - Grouped errors by section and invoice for structured reporting. - Added clickable invoice links in error messages for easy navigation. - Scheduled detailed activities for invoices with errors. - Enhanced code readability and maintainability. This ensures clearer error reports, efficient activity creation, and easier future updates. Forward-Port-Of: odoo/enterprise#76880
Original PR description
In this PR: - Refactored error handling for better clarity and organization. - Grouped errors by section and invoice for structured reporting. - Added clickable invoice links in error messages for easy navigation. - Scheduled detailed activities for invoices with errors. - Enhanced code readability and maintainability. This ensures clearer error reports, efficient activity creation, and easier future updates. Forward-Port-Of: odoo/enterprise#76880
Forward-Port-Of: odoo/enterprise#77290 Forward-Port-Of: odoo/enterprise#77126
Original PR description
Forward-Port-Of: odoo/enterprise#77290 Forward-Port-Of: odoo/enterprise#77126
Forward-Port-Of: odoo/enterprise#75568
Original PR description
Forward-Port-Of: odoo/enterprise#75568
Currently, an error occurs when opening a preview of an invoice without an invoice date Step to produce: - Install the `l10n_ec_edi` module (with demo data). - Change a current company to 'EC Company', which has an 'Ecuador' country. - Create a new invoice, add a customer name, payment terms, and invoice line, save the record, - Click on the 'Preview' button (ensure that the invoice has no date). ```TypeError: unsupported operand type(s) for -: 'bool' and 'datetime.date'``` An err
Original PR description
Currently, an error occurs when opening a preview of an invoice without an invoice date Step to produce: - Install the `l10n_ec_edi` module (with demo data). - Change a current company to 'EC Company', which has an 'Ecuador' country. - Create a new invoice, add a customer name, payment terms, and invoice line, save the record, - Click on the 'Preview' button (ensure that the invoice has no date). ```TypeError: unsupported operand type(s) for -: 'bool' and 'datetime.date'``` An error occurs when the system attempts to calculate payment term days at [1], with using an invoice date, but it is not available. Link [1]: https://github.com/odoo/enterprise/blob/26aa95079af2a868c2991c7f19daee5328d5bb01/l10n_ec_edi/models/account_move.py#L440C22-L440C93 To resolve this issue, Provide a default day zero(0) for the payment term, if invoice date is not available. Sentry-6015854429 Forward-Port-Of: odoo/enterprise#76881 Forward-Port-Of: odoo/enterprise#72864