Friday, May 7, 2021
15 changes · master
Resolved issues and error corrections
Manufacturing bills of materials now show only relevant units of measure for by-products, based on the selected product’s unit category. This helps users avoid choosing incompatible units and reduces data entry mistakes in manufacturing setup.
Original PR description
Before this commit, It was always showing all Unit of Measures in By Product lines. With this commit, We are showing UoMs based on Category of Selected Product's UoM. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The PDF viewer in Odoo mobile app webviews now hides actions that do not work reliably there, including print, download, and open file. This avoids showing users buttons that fail or are not meaningful in the mobile app context, while keeping other ways to access or download files available.
Original PR description
Some features of the PDF.js library doesn't work in the webview of the mobile apps. Initially 'window.print' is defined as an empty function in webviews unlike browsers where it is already ready. After that, PDF.js needs to monkey patch 'window.print' and saves a reference to the original definition, which is not yet fulfilled in by the mobile app (Java part). So the print of PDF.js doesn't work in webviews and end users will need to download the file before printing it. Regarding the Download button, the 'download' attribute is not supported by the webview as you can see in: https://bugs.chromium.org/p/chromium/issues/detail?id=432414 As there's many ways to download a file in Odoo it's not a big deal to simply hide it in PDF.js. Because it's quite complicated to fix this, we decided to hide the features that don't work (Download / Print) or don't make sense (Open file). Task-id: 2200168
Miscellaneous changes
`_(xyz)` will wrap `xyz`` in an underscore.js object, which when used in a string context will just return the string. So it's basically a no-op, but it certainly doesn't translate the terms. Forward-Port-Of: odoo/odoo#70127 Forward-Port-Of: odoo/odoo#70000
Original PR description
`_(xyz)` will wrap `xyz`` in an underscore.js object, which when used in a string context will just return the string. So it's basically a no-op, but it certainly doesn't translate the terms. Forward-Port-Of: odoo/odoo#70127 Forward-Port-Of: odoo/odoo#70000
# IMPACTED VERSIONS 12.0+ # HOW TO REPRODUCE ``` locale : Locale is en_US (or other SUNDAY based) view: CRM - My Pipeline - Kanban view groupBy: date_deadline:week (Expected closing) records: one record with a planned activity, on date_deadline = 2021-05-02 (SUNDAY) one record with no planned activity, on date_deadline = 2021-05-09 (SUNDAY) remark: don't keep any other record in MAY for better visibility ``` # PROBLEM The progressbar of the week containin
Original PR description
# IMPACTED VERSIONS 12.0+ # HOW TO REPRODUCE ``` locale : Locale is en_US (or other SUNDAY based) view: CRM - My Pipeline - Kanban view groupBy: date_deadline:week (Expected closing) records: one…
# IMPACTED VERSIONS
12.0+
# HOW TO REPRODUCE
```
locale : Locale is en_US (or other SUNDAY based)
view: CRM - My Pipeline - Kanban view
groupBy: date_deadline:week (Expected closing)
records: one record with a planned activity, on date_deadline = 2021-05-02 (SUNDAY)
one record with no planned activity, on date_deadline = 2021-05-09 (SUNDAY)
remark: don't keep any other record in MAY for better visibility
```
# PROBLEM
The progressbar of the week containing 2021-05-09 displays information about the record
from the week containing 2021-05-02
# CAUSE
1. PostgreSQL `date_trunc` function follows ISO8601 which essentially means that
the start of a WEEK is always MONDAY. There is no argument to change this.
2. _read_group_format_result
https://github.com/odoo/odoo/blob/27da86a138089c1838e4b94f8a6976995b9c1fff/odoo/models.py#L2210-L2219
- Computes a label for a group of records.
- Follows the locale for the label of the week, based on a date which was
always a MONDAY because of how `date_trunc` was used previously.
3. read_progress_bar
https://github.com/odoo/odoo/blob/88957afca09662af7eaa19df1e40b3699e45e79e/addons/web/models/models.py#L167-L175
- Associates a group label to a record.
- Follows the locale for the label of the week, based on the date of a record
which can be any day of the week. If the record is related to a SUNDAY and
SUNDAY is the first day of the week, it would have been in a group with a
different label in (2.) than in (3.) prior to this change.
# FIX
In 3., before associating a label to a record, we truncate the date to the
ISO start of the period, so that the label is determined for a record in the
same conditions than in 2. The locale is still used to get language-dependent
outputs with babel, but the grouping will always follows ISO8601 (date_trunc).
# TEST
Added a test for this problem case
TASK-ID : 2517848
Forward-Port-Of: odoo/odoo#70475
Forward-Port-Of: odoo/odoo#69946Base: seems related fields take only 1 extra query instead of 3 Crm: assignment seems to have been slightly improved. Some randomness still happens. Hr Holidays: seems it was further improved beyond space frontier Test mail: those tests were a bit random, seems random is gone (hopefully) Test mail full: updated local counters Test mass mailing: seems we gained one query, updated local counters Forward-Port-Of: odoo/odoo#70491
Original PR description
Base: seems related fields take only 1 extra query instead of 3 Crm: assignment seems to have been slightly improved. Some randomness still happens. Hr Holidays: seems it was further improved beyond space frontier Test mail: those tests were a bit random, seems random is gone (hopefully) Test mail full: updated local counters Test mass mailing: seems we gained one query, updated local counters Forward-Port-Of: odoo/odoo#70491
BEFORE this commit query "invoices is not set" was tranformed to query "order_line.invoice_lines.invoice_id is False", which doesn't make sense, because invoice_id is required fields and hence always set. Hence, result of the query was always empty. AFTER: just check that there is no invoice_lines. Strictly speacking, is not the same as checking result of compute method, but because invoice_lines are supposed to be lines for invoices of out_* type, the result should be the same. ---
Original PR description
BEFORE this commit query "invoices is not set" was tranformed to query "order_line.invoice_lines.invoice_id is False", which doesn't make sense, because invoice_id is required fields and hence always set. Hence, result of the query was always empty. AFTER: just check that there is no invoice_lines. Strictly speacking, is not the same as checking result of compute method, but because invoice_lines are supposed to be lines for invoices of out_* type, the result should be the same. --- opw-2516124 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#70493 Forward-Port-Of: odoo/odoo#70343
What are the steps to reproduce your issue ? 1. Go to Account/Journal Items 2. Open a posted item 3. Change product What is currently happening ? The product is changed in the account move What are you expecting to happen ? The account move lines cannot be changed when the status is posted How to fix the bug ? Make the field read-only when the status is posted opw-2517325 Forward-Port-Of: odoo/odoo#70516 Forward-Port-Of: odoo/odoo#70383
Original PR description
What are the steps to reproduce your issue ?
1. Go to Account/Journal Items
2. Open a posted item
3. Change product
What is currently happening ?
The product is changed in the account move
What are you expecting to happen ?
The account move lines cannot be changed when the status is posted
How to fix the bug ?
Make the field read-only when the status is posted
opw-2517325
Forward-Port-Of: odoo/odoo#70516
Forward-Port-Of: odoo/odoo#70383…ding accounts - Share outstanding accounts between multiple journals - Create payment for each of them - Go to dashboard => "Outstanding Payments/Receipts" amounts are wrong ticket: 2517499 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#70262
Original PR description
…ding accounts - Share outstanding accounts between multiple journals - Create payment for each of them - Go to dashboard => "Outstanding Payments/Receipts" amounts are wrong ticket: 2517499 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#70262
Forward-Port-Of: odoo/enterprise#18218
Original PR description
Forward-Port-Of: odoo/enterprise#18218
When validating a PO, the product's country is not saved on the account move line. Therefore, this information is missing in intrastat report. To reproduce the error: (Need purchase. Use a BE company) 1. In Settings, enable "Intrastat" 2. Create a product P - Accounting > Country of Origin: France 3. Create a vendor V - Must be European but not Belgian 4. Create a PO - Vendor: V - Product: P 5. Set the received quantity 6. Create Bill, Confirm 7. Accounting > Repo
Original PR description
When validating a PO, the product's country is not saved on the account
move line. Therefore, this information is missing in intrastat report.
To reproduce the error:
(Need purchase. Use a BE company)
1. In Settings, enable "Intrastat"
2. Create a product P
- Accounting > Country of Origin: France
3. Create a vendor V
- Must be European but not Belgian
4. Create a PO
- Vendor: V
- Product: P
5. Set the received quantity
6. Create Bill, Confirm
7. Accounting > Reporting > Intrastat Report
Error: The "Origin Country" of the line is "QU". It should be "FR".
This fix suggests to convert the `onchange` method into a `compute` one
since:
- The body is the expected behaviour
- This is not the initial `_onchange_product_id`, so the overrides are
not lost
OPW-2474599
Forward-Port-Of: odoo/enterprise#18069Forward-Port-Of: odoo/enterprise#18188 Forward-Port-Of: odoo/enterprise#18103
Original PR description
Forward-Port-Of: odoo/enterprise#18188 Forward-Port-Of: odoo/enterprise#18103
Doing "1 Employee" -> "Request Appraisal" send a mail with a button linking to the appraisal. Doing "1 Appraisal" -> "Confirm" sends a mail without any link to the appraisal. In this changeset, we provides values for `recipient_users` and `url` that are used in the default mail template to show the button. opw-2486362 Forward-Port-Of: odoo/enterprise#18169
Original PR description
Doing "1 Employee" -> "Request Appraisal" send a mail with a button linking to the appraisal. Doing "1 Appraisal" -> "Confirm" sends a mail without any link to the appraisal. In this changeset, we provides values for `recipient_users` and `url` that are used in the default mail template to show the button. opw-2486362 Forward-Port-Of: odoo/enterprise#18169
Hr Payroll: seems somehow we gained 2 queries Forward-Port-Of: odoo/enterprise#18185
Original PR description
Hr Payroll: seems somehow we gained 2 queries Forward-Port-Of: odoo/enterprise#18185
What are the steps to reproduce your issue ? 1. Open https://solute-staging-1688464.dev.odoo.com/ 2. Open app "Accounting" 3. Open general ledger and click on button "DATEV Export" (see attachment) 4. Download the DATEV Export CSV files and open them. What is currently happening ? The invoice number INV/2020/00002 is cut off to V/20020/00002 (see attachment). If we would reduce two digits in the invoice number range, then Odoo would cut off less. What ar
Original PR description
What are the steps to reproduce your issue ?
1. Open https://solute-staging-1688464.dev.odoo.com/
2. Open app "Accounting"
3. Open general ledger and click on button "DATEV Export" (see attachment)
4. Download the DATEV Export CSV files and open them.
What is currently happening ?
The invoice number INV/2020/00002 is cut off to V/20020/00002 (see attachment).
If we would reduce two digits in the invoice number range, then Odoo would cut off less.
What are you expecting to happen ?
Don't cut off invoice number
Why is this happening ?
Because the limit fixed by datev was 12, but now the specs have changed to 36
How to fix the bug ?
Cut 36 chars instead of 12
opw-2381771
Forward-Port-Of: odoo/enterprise#18166`_()` is essentially a no-op. While at it, stylistically fixed some of the bits: * avoided concatenations of text and markup being fed to jQuery's constructors, built the tree using jQuery and used `.text`/`text:` to set the inner text * `sprintf` rather than concatenation when relevant * migrated one of the `do_warn` calls near an edition site to `displayNotification` Linked to community PR odoo/odoo#70000 Forward-Port-Of: odoo/enterprise#18047 Forward-Port-Of: odoo/enterprise#18001
Original PR description
`_()` is essentially a no-op. While at it, stylistically fixed some of the bits: * avoided concatenations of text and markup being fed to jQuery's constructors, built the tree using jQuery and used `.text`/`text:` to set the inner text * `sprintf` rather than concatenation when relevant * migrated one of the `do_warn` calls near an edition site to `displayNotification` Linked to community PR odoo/odoo#70000 Forward-Port-Of: odoo/enterprise#18047 Forward-Port-Of: odoo/enterprise#18001