Monday, January 18, 2021
26 changes · master
Enhancements to existing features
This change improves how Odoo runs follow-up actions after a web request has finished. It helps internal processes complete more reliably without affecting day-to-day user workflows.
Original PR description
Task: 2416741
The Expense app now uses the clearer term “category” instead of “product” when employees record or manage expenses. This better matches how business users think about expenses and reduces confusion caused by internal product setup terminology.
Original PR description
Currently at odoo we use expense product terminology just because it's set up using product. Inside the expense app, there is no reason of not using category So in this commit, rename the product into category TaskId: 2391433 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
The default administrator signature now uses the admin user's actual name, Mitchell Admin, instead of the generic 'Administrator'. This creates a more personalized onboarding experience for new Odoo users.
Original PR description
PURPOSE Currently, the signature of the admin defaults to 'administrator'. Odoo does not take into account the actual name of the user. The onboarding experience would be better if the signature was personalized for the user. SPECIFICATIONS The default signature of the admin is his name (Mitchell Admin) instead of 'Administrator'. LINKS PR https://github.com/odoo/odoo/pull/63914 Task-2416715
Geolocation fields now store more precise latitude and longitude values, matching the precision used by Google and Odoo's Sign app. This reduces rounding issues and helps improve the accuracy of customer and lead locations.
Original PR description
Before this commit:
- The precision on geolocalisation fields were set to (16,5) which
caused rounding when data was comming from Goolge.
After this commit:
- The precision on geolocalisation fields are set to (10,7) which is
aligned with what Google does.
This precision of (10,7) is actually already used in the Sign App.
task-2426985
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThe accounting reports activity view now hides the “Mark as Done” button for tax report activities. This prevents users from taking an inappropriate action and keeps the activity workflow clearer for tax-related tasks.
Original PR description
**PURPOSE** After installing account_reports in current activity view button "mark as done" is visible even though "activity_category" is "tax_report". **SPECIFICATION** Adding an inherited record in account_reports module to invisible "Mark as Done" button when "activity_category" is "tax_report". **LINKS** PR https://github.com/odoo/enterprise/pull/15281 Task-2371023
Documentation and clarification updates
This pull request adds a signed contributor agreement record for jlalfonso21. It is an administrative legal update that confirms the contributor can submit work under Odoo's contribution rules, with no direct product impact.
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
Miscellaneous changes
**Description of the issue/feature this PR addresses:** Until now, when no matches were found between warehouse ids and the context.allowed_company id, clicking the forecasted_qty button on a product would lead to a traceback. This is because in get_filter_state, the 'active_warehouse' used to correspond to a company id, which was irrelevant. **Current behavior before PR:** We modify get_filter_state so that 'active_warehouse' now corresponds to a warehouse with that company id instead.
Original PR description
**Description of the issue/feature this PR addresses:** Until now, when no matches were found between warehouse ids and the context.allowed_company id, clicking the forecasted_qty button on a product would lead to a traceback. This is because in get_filter_state, the 'active_warehouse' used to correspond to a company id, which was irrelevant. **Current behavior before PR:** We modify get_filter_state so that 'active_warehouse' now corresponds to a warehouse with that company id instead. **Desired behavior after PR is merged:** Clicking the forecasted_qty button on a product not lead to a traceback in any circumstance. opw-2418559 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#64222
The tracking system causes some performances issues, this fix will allow to bypass the tracking for heavy tasks. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#64574 Forward-Port-Of: odoo/odoo#64561
Original PR description
The tracking system causes some performances issues, this fix will allow to bypass the tracking for heavy tasks. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#64574 Forward-Port-Of: odoo/odoo#64561
From Invoice list view select 2+ invoices (A, B), click Action>send and print In each invoice 2 invoices will be sent: - In A, you'll find A and A - In B, you'll find A and B This occur because the composition_mode of the composer is computed after the attachment has been generated. When the composer has an attachment, it is included into the sent mail along the relevant one, generated on the fly for each record. opw-2428544 Description of the issue/feature this PR addresses: C
Original PR description
From Invoice list view select 2+ invoices (A, B), click Action>send and print In each invoice 2 invoices will be sent: - In A, you'll find A and A - In B, you'll find A and B This occur because the composition_mode of the composer is computed after the attachment has been generated. When the composer has an attachment, it is included into the sent mail along the relevant one, generated on the fly for each record. opw-2428544 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#64360
In order to clarify the purpose of the account_lock module, slightly update its description. Task id #2382740 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#63394
Original PR description
In order to clarify the purpose of the account_lock module, slightly update its description. Task id #2382740 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#63394
When reconciling a statement line with multiple lines in a multi-currency environment, it could lead to a rounding issue due to the currency rates. It could lead to an auto-generated open-balance of 0.01 amount to auto-balance the journal entry but the result is wrong since the partner has an open amount left on the receivable/payable account. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#64620
Original PR description
When reconciling a statement line with multiple lines in a multi-currency environment, it could lead to a rounding issue due to the currency rates. It could lead to an auto-generated open-balance of 0.01 amount to auto-balance the journal entry but the result is wrong since the partner has an open amount left on the receivable/payable account. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#64620
`product_name` is correct variable name. Followup on https://github.com/odoo/odoo/blame/755bdbeb04a769bf1fcf9157f74d6a5deb4ad48d/addons/sale_project/models/project.py#L68 Fixes #64097 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#64296
Original PR description
`product_name` is correct variable name. Followup on https://github.com/odoo/odoo/blame/755bdbeb04a769bf1fcf9157f74d6a5deb4ad48d/addons/sale_project/models/project.py#L68 Fixes #64097 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#64296
BEFORE: sms templates from these modules become inaccessible if any module from the list below is installed * crm_sms * event_sms * stock_sms * enterprise/account_followup * enterprise/marketing_automation_sms * enterprise/sale_subscription those modules add security rules for sms.templates, which adds additional conditions to get access: at least one security rule has to be passed. So, we need to add such rules to get access not only to Superuser --- opw-2411116 Descripti
Original PR description
BEFORE: sms templates from these modules become inaccessible if any module from the list below is installed * crm_sms * event_sms * stock_sms * enterprise/account_followup * enterprise/marketing_automation_sms * enterprise/sale_subscription those modules add security rules for sms.templates, which adds additional conditions to get access: at least one security rule has to be passed. So, we need to add such rules to get access not only to Superuser --- opw-2411116 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#64626
Forward-Port-Of: odoo/odoo#64396
Original PR description
Forward-Port-Of: odoo/odoo#64396
It may happen that the customer did reconcile some of his account.move.line prior the closing of the session. As it is not possible to reconcile an already reconciled account.move.line, it triggers an error. After discussing with JCB, it turns out that it is safe enough to ignore the account.move.line that are already reconciled. opws: 2374559 2376187 2377958 2391395 2425197 Forward-Port-Of: odoo/odoo#64415
Original PR description
It may happen that the customer did reconcile some of his account.move.line prior the closing of the session. As it is not possible to reconcile an already reconciled account.move.line, it triggers an error. After discussing with JCB, it turns out that it is safe enough to ignore the account.move.line that are already reconciled. opws: 2374559 2376187 2377958 2391395 2425197 Forward-Port-Of: odoo/odoo#64415
Forward-Port-Of: odoo/odoo#64666
Original PR description
Forward-Port-Of: odoo/odoo#64666
WHY: it's computed field that is not supposed to be editable. In previous task it was asked to make it visible, not editable. --- opw-2431011 https://github.com/odoo/odoo/commit/8b7861ddabf92f85aff7665cb5bd79922676f545 task-2300936 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#64521
Original PR description
WHY: it's computed field that is not supposed to be editable. In previous task it was asked to make it visible, not editable. --- opw-2431011 https://github.com/odoo/odoo/commit/8b7861ddabf92f85aff7665cb5bd79922676f545 task-2300936 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#64521
Let's assume the following scenario with 'purchase_product_matrix' module installed: - create a new Purchase Order - add a line in the one2many - select "Customizable desk" as product - [the desk matrix opens] - close the matrix - select "Conference chair" instead - [the desk matrix opens, whereas it should be the chair one] It didn't work because of a small bug in the FieldOne2Many. This field is configured to be reset when any other field in the view changes. The product co
Original PR description
Let's assume the following scenario with 'purchase_product_matrix' module installed: - create a new Purchase Order - add a line in the one2many - select "Customizable desk" as product - [the desk…
Let's assume the following scenario with 'purchase_product_matrix' module installed: - create a new Purchase Order - add a line in the one2many - select "Customizable desk" as product - [the desk matrix opens] - close the matrix - select "Conference chair" instead - [the desk matrix opens, whereas it should be the chair one] It didn't work because of a small bug in the FieldOne2Many. This field is configured to be reset when any other field in the view changes. The product configurator feature relies on that. However, when another field changes, the One2Many didn't update its internal state with the new record (and it skipped the rendering, which is fine). The matrix product configurator thus read an obsolete value in the internal of the one2many. opw~2421798 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#64552
When using a tracked product in a MO, the lot/serial number reservation disappears even if the product is still reserved. To reproduce the error: (Need mrp) 1. Create two products P and P_compo - Both are storable - P_compo is tracked by lots 2. Update P_compo's quantity - Set the on hand quantity of lot L to 5 3. Create a MO - Product: P - Quantity: 5 - Add a line: (Product: P_compo, To Consume: 5) 4. Confirm 5. Check availability - The P_compo's reserved quantity has be
Original PR description
When using a tracked product in a MO, the lot/serial number reservation disappears even if the product is still reserved. To reproduce the error: (Need mrp) 1. Create two products P and P_compo -…
When using a tracked product in a MO, the lot/serial number reservation disappears even if the product is still reserved. To reproduce the error: (Need mrp) 1. Create two products P and P_compo - Both are storable - P_compo is tracked by lots 2. Update P_compo's quantity - Set the on hand quantity of lot L to 5 3. Create a MO - Product: P - Quantity: 5 - Add a line: (Product: P_compo, To Consume: 5) 4. Confirm 5. Check availability - The P_compo's reserved quantity has been updated to 5. If you click on the line's details, you can see that 5 P_compo has been reserved from lot L 6. Back to the MO, in edit mode, change the done quantity: 3/5 - There are still 5 reserved P_compo 7. Click on the P_compo's line details ERR: the line we saw on step 5 disappeared. The MO says that 5 P_compo are reserved, but when checking which lot is reserved, the latter is no more visible. Moreover, if you click on "Confirm" (so you leave the "Detailed Operations" pop-up), the "Reserved" field of the line will be reset. The lot reservation should stay so the user can complete the "Done" field. OPW-2420347 Forward-Port-Of: odoo/odoo#63941
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#64656
Original PR description
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#64656
Issue - Install "Accounting" module - Create a new bill : - Set vendor - Set no payment reference - Set a bill reference - Add products to bill - Confirm and click on Register Payment Memo field has no value. Cause The memo field is based on lines name. Lines name is computed in `_onchange_payment_reference` and depends only on payment_referecence. Solution If no `payment_reference`, fallback on `ref` to set line name. opw-2440389 Forward-Port-Of: odoo/o
Original PR description
Issue - Install "Accounting" module - Create a new bill : - Set vendor - Set no payment reference - Set a bill reference - Add products to bill - Confirm and click on Register Payment Memo field has no value. Cause The memo field is based on lines name. Lines name is computed in `_onchange_payment_reference` and depends only on payment_referecence. Solution If no `payment_reference`, fallback on `ref` to set line name. opw-2440389 Forward-Port-Of: odoo/odoo#64618
Forward-Port-Of: odoo/odoo#64691 Forward-Port-Of: odoo/odoo#64593
Original PR description
Forward-Port-Of: odoo/odoo#64691 Forward-Port-Of: odoo/odoo#64593
Bug === Since 18299d7e5051cdad29854bc7280db5002a209500 we use the new Python API to send email. So we now use EmailMessage instead of MIMEText. But we forgot to specify the charset for the headers (the charset is specified for the body and for the alternative body but not for the headers itself). Task 2393865 Forward-Port-Of: odoo/odoo#64651
Original PR description
Bug === Since 18299d7e5051cdad29854bc7280db5002a209500 we use the new Python API to send email. So we now use EmailMessage instead of MIMEText. But we forgot to specify the charset for the headers (the charset is specified for the body and for the alternative body but not for the headers itself). Task 2393865 Forward-Port-Of: odoo/odoo#64651
Traceback was raised here totals[id][1] += values['balance'] * values['account_rate'] / 100 with TypeError: unsupported operand type(s) for *: 'float' and 'NoneType' because account_rate was None instead of 0 opw:2442217 Forward-Port-Of: odoo/enterprise#15804
Original PR description
Traceback was raised here totals[id][1] += values['balance'] * values['account_rate'] / 100 with TypeError: unsupported operand type(s) for *: 'float' and 'NoneType' because account_rate was None instead of 0 opw:2442217 Forward-Port-Of: odoo/enterprise#15804
When the vehicle model is a type bike and you have used that bike from 'Customize your salary' then it will create a vehicle Task-Id: 2372530 Forward-Port-Of: odoo/enterprise#15012
Original PR description
When the vehicle model is a type bike and you have used that bike from 'Customize your salary' then it will create a vehicle Task-Id: 2372530 Forward-Port-Of: odoo/enterprise#15012
Steps to reproduce the bug: - Let's consider two company C1 and C2 which synchronize SO/PO - Let's consider two purchase taxes T1 and T2 in C2 - Let's consider a fiscal position FP in C2 that T1 to T2 - Let's consider a shared product P with T1 as supplier tax (in C2) - Set FP on partner C1 in C2 (when logged in C2) - From C1, create a SO with C2 as customer, add P and confirm the SO Bug: A PO was created in C2 with C1 as vendor but T1 was set on the line instead of T2 even if FP
Original PR description
Steps to reproduce the bug: - Let's consider two company C1 and C2 which synchronize SO/PO - Let's consider two purchase taxes T1 and T2 in C2 - Let's consider a fiscal position FP in C2 that T1 to T2 - Let's consider a shared product P with T1 as supplier tax (in C2) - Set FP on partner C1 in C2 (when logged in C2) - From C1, create a SO with C2 as customer, add P and confirm the SO Bug: A PO was created in C2 with C1 as vendor but T1 was set on the line instead of T2 even if FP was set on the PO This commit standardizes the taxes computation behavior with sale orders, purchase orders and invoices. This computation is just an encoding help that fetches the product taxes from the destination comapny C and maps these taxes with a possible fiscal position of C opw:2426250 Forward-Port-Of: odoo/enterprise#15765 Forward-Port-Of: odoo/enterprise#15751