Wednesday, April 15, 2020
16 changes · master
Enhancements to existing features
Customer and lead enrichment details from Clearbit are now shown using one shared format across partner creation, lead enrichment, and lead generation. This reduces inconsistent notes, makes sales information easier to read, and keeps extra email addresses available in the detail note while using only the first email on generated leads.
Original PR description
PURPOSE We make multiple calls to the clearbit API and the returned information are shown in various different templates, although they contain the same information. The purpose of this commit is to…
PURPOSE We make multiple calls to the clearbit API and the returned information are shown in various different templates, although they contain the same information. The purpose of this commit is to unify the templates into a single one to reduce code size and improve coherence. SPECIFICATIONS Currently, we have 3 ways of reaching out to the IAP clearbit api: - When creating a partner (autocomplete service) - When enriching an existing lead based on its email address - When generating leads using the "Geneate Leads" button or using the website visitors Every time we use the service, we log a note in the model's chatter containing all the information returned by the cleabit service (estimated annual revenue, media links, sector, ...). Though using different endpoints and methods, all the calls essentially return the same data, and the templates could be unified for consistency. This is the goal of this commit. We merge the 3 separate templates of each modules into a unique template that always renders the same information to the end user. To do that, we had to find a common module to store the template, we chose "partner_autocomplete" as it's installed anyway as soon as "crm_iap_lead_*" is installed. LINKS PR #40349 Task 2081471
Code cleanup and technical improvements
This update rewrites parts of Odoo's messaging experience used across calendar, CRM, HR time off, and live chat. It should make these communication areas easier to maintain and prepare them for smoother future improvements, with some visible changes in chat, activity menus, and discussion panels.
Miscellaneous changes
Set a default email signature to an empty string to avoid `False` when evaluating `${user.signature | safe}` in email templates. opw-2229846 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#49367
Original PR description
Set a default email signature to an empty string to avoid `False` when
evaluating `${user.signature | safe}` in email templates.
opw-2229846
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#49367When the Decimal Accuracy for "Product UoM" is set as "6" and the quantity to be manufactured is having digits up to 6 decimal places, the decoration of the lines is incorrect. This happens because of Float representation at the JavaScript level, leading to comparison such as: `451.099999...8 < 451.1` It's not possible to use some kind of rounded comparison. As a workaround, we change the way the float are compared. opw-2234824 Description of the issue/feature this PR addresse
Original PR description
When the Decimal Accuracy for "Product UoM" is set as "6" and the quantity to be manufactured is having digits up to 6 decimal places, the decoration of the lines is incorrect. This happens because of Float representation at the JavaScript level, leading to comparison such as: `451.099999...8 < 451.1` It's not possible to use some kind of rounded comparison. As a workaround, we change the way the float are compared. opw-2234824 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#49540 Forward-Port-Of: odoo/odoo#49427
1. merge intra community taxes (one taxe with two report lines instead of two taxes with one report line each) 2. fix "tva à l'encaissement" fiscal position mapping (two rates were using the same xml_id) 3. add outside EU import taxes It seems git diff is fucked up. It doesn't match the correct lines... -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#49186
Original PR description
1. merge intra community taxes (one taxe with two report lines instead of two taxes with one report line each) 2. fix "tva à l'encaissement" fiscal position mapping (two rates were using the same xml_id) 3. add outside EU import taxes It seems git diff is fucked up. It doesn't match the correct lines... -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#49186
The default account was never set when adding a new line because the key was missing from overriden context -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#49579 Forward-Port-Of: odoo/odoo#49545
Original PR description
The default account was never set when adding a new line because the key was missing from overriden context -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#49579 Forward-Port-Of: odoo/odoo#49545
In invoice portal view the state field is not well migrated (during 12.0 => 13.0). -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#49468 Forward-Port-Of: odoo/odoo#48997
Original PR description
In invoice portal view the state field is not well migrated (during 12.0 => 13.0). -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#49468 Forward-Port-Of: odoo/odoo#48997
The custom selection widget was only used in the form. A small rework had to be done to make it work in list views because the values were not pre loaded. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#49534
Original PR description
The custom selection widget was only used in the form. A small rework had to be done to make it work in list views because the values were not pre loaded. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#49534
Remove the z-index = 1 for the header because it introduces visuals bugs where certain elements are displayed at the top of the header when should be displayed under. Example: search button in events page. task-2229057 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#49586
Original PR description
Remove the z-index = 1 for the header because it introduces visuals bugs where certain elements are displayed at the top of the header when should be displayed under. Example: search button in events page. task-2229057 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#49586
Issue ===== - The transaction crashed when you have a backward and measure != count because the list of record to be removed were actually not record but bool - in addition, the len of the list return the wrong value since False and True are both count as element of the list - The record with no date_close should be consider out of the backward timeline as well - finally the case where the measure is a many2one was not handle
Original PR description
Issue ===== - The transaction crashed when you have a backward and measure != count because the list of record to be removed were actually not record but bool - in addition, the len of the list…
Issue
=====
- The transaction crashed when you have a backward and measure != count
because the list of record to be removed were actually not record but bool
- in addition, the len of the list return the wrong value since False
and True are both count as element of the list
- The record with no date_close should be consider
out of the backward timeline as well
- finally the case where the measure is a many2one
was not handle properly
PERFORMANCE
============
Improve the performance of the transaction
Transaction query was in O(n*m)
n: number of raw
m: number au column
Now it's only in O(n)
using read_group
The new design fix the issues describe above
TEST
====
add test for the backend of web_cohort
Check Main use case
timeline: forward, backward
interval: day, week, month, year
measure: __count__, float, many2one
mode: retention, churn
Forward-Port-Of: odoo/enterprise#9379In case we receive a structured communication, it was not the only information that was passed to the statement_line reference, therefore the process to reconcile entries automatically was not working. With this fix, we only set as statement line reference the communication if that communication is a structured communication Forward-Port-Of: odoo/enterprise#9920
Original PR description
In case we receive a structured communication, it was not the only information that was passed to the statement_line reference, therefore the process to reconcile entries automatically was not working. With this fix, we only set as statement line reference the communication if that communication is a structured communication Forward-Port-Of: odoo/enterprise#9920
When we validated a line with the reconciliation widget, it took us back to the top of the screen instead of continuing with the next. Forward-Port-Of: odoo/enterprise#9791
Original PR description
When we validated a line with the reconciliation widget, it took us back to the top of the screen instead of continuing with the next. Forward-Port-Of: odoo/enterprise#9791
opw-2236938 Forward-Port-Of: odoo/enterprise#9899
Original PR description
opw-2236938 Forward-Port-Of: odoo/enterprise#9899
When a signature item original value is eg.: - a string containing only "0" - an integer with value 0 The system think there is no value because we use jQuery.data that try to match the data to javascript value, so `data-value="0"` is gotten as integer 0 which is falsy. opw-2217325 Forward-Port-Of: odoo/enterprise#9895 Forward-Port-Of: odoo/enterprise#9825
Original PR description
When a signature item original value is eg.: - a string containing only "0" - an integer with value 0 The system think there is no value because we use jQuery.data that try to match the data to javascript value, so `data-value="0"` is gotten as integer 0 which is falsy. opw-2217325 Forward-Port-Of: odoo/enterprise#9895 Forward-Port-Of: odoo/enterprise#9825
XML: generation crashed when more than 1 payment in batch payment View: In batch payment view, could change sdd scheme even after batch payment was sent Forward-Port-Of: odoo/enterprise#9816
Original PR description
XML: generation crashed when more than 1 payment in batch payment View: In batch payment view, could change sdd scheme even after batch payment was sent Forward-Port-Of: odoo/enterprise#9816
- Create a subscription with a product P - Upsell with the same product - In the SO, change the price unit, validate The product is merged in the subscription, while it should be on a seprate line. opw-2227581 Forward-Port-Of: odoo/enterprise#9877
Original PR description
- Create a subscription with a product P - Upsell with the same product - In the SO, change the price unit, validate The product is merged in the subscription, while it should be on a seprate line. opw-2227581 Forward-Port-Of: odoo/enterprise#9877