Daily updates from Odoo
Thursday, December 12, 2019
5 changes · master
Enhancements to existing features
This update begins moving Odoo's mail and Discuss experience to a newer interface framework while keeping messaging responsive during loading. It should improve maintainability and prepare the product for future user-facing mail enhancements, with some visible loading behavior improvements in the messaging menu.
Sales teams can now find leads and opportunities by searching for a phone or mobile number, even if the number is typed without spaces or country-formatting symbols. This helps call center staff quickly identify a caller's open opportunities while limiting very short searches to avoid performance issues.
Original PR description
Allow users to look for leads and opportunities by using the phone number fields. This, for example, allows salesmen working in call centers to quickly retrieve all open opportunities of a specific person calling (with its phone number appearing). task-2122873
Website courses now calculate and display an estimated duration based on videos, PDFs, and manually entered slide times, excluding archived content. This helps learners understand the time commitment before starting a course, with durations shown in a clearer rounded format such as minutes or hours and minutes.
Original PR description
The duration of a course is now computed. The duration is equal the sum of the duration of all videos, plus the estimated time to read any PDF, plus the duration encoded on the other slides. The other types of slide have a field to encode the duration during its creation (not mandatory). Also, the computation take only the slides that are not archive. The format of the duration of a course on its tile is modified. It's now displayed like this : "x min" or "y hours x min". The duration displayed is also rounded to quarter of hour. Task ID : 2007294 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Subscriptions can now carry their own taxes and fiscal positions, instead of relying only on product and customer defaults. This improves invoice accuracy, renewal and upsell consistency, and TaxCloud payment flows so charged amounts better match final invoices.
Original PR description
Purpose ======= This commit introduces the notion of taxes and fiscal position in subscription models. This change was motivated by the fact that you cannot currently properly manage taxes on…
Purpose ======= This commit introduces the notion of taxes and fiscal position in subscription models. This change was motivated by the fact that you cannot currently properly manage taxes on subscriptions: if you are not in the default case where your subscription is supposed to use the default taxes from a product with the default fiscal position of the partner, you're out of luck. Unlike sale, purchase, account, etc. where you can override the defaults - this was a serious limitation. In addition, this change was also motivated by the fact that the integration with TaxCloud of the subscription module was hastily put together to counteract some nasty side-effects (e.g. a payment is done in automated processing mode but upon validation of the invoice, taxes sent by taxcloud change - the amount you just authorized on the payment method no longer matches the invoice you're trying to pay). Specifications ============== For consistency across modules, this borrows most of the logic from the sale module. - `sale.subscription.line` gets a m2m tax field as well as stored computed fields for untaxed, taxed and total prices - `sale.subscription` gets a fiscal position as well as stored computed fields for untaxed, taxed and total prices - taxes and fiscal position are forwarded from the initial SO upon creation *AND* upon renewal and upsell - taxes and fiscal position are forward upon invoice generation Migration Strategy ================== 1/ Add *default taxes* based on the product and partner (*do not* try to guess the taxes from the initial SO - existing subscriptions have been generating invoices with the default taxes prior to this, making this a mandatory choice for the migration) 2/ Recompute totals for lines This recomputation should not be done in SQL, since it is based on taxes that could be included or excluded, fiscal position mapping, currency rounding and the like. Use Python code to do this. A possible strategy to improve perfs should we need to (although I do not expect a lot of database with *millions* of subscriptions to actually exist) is similar to what we did in v12 for `pos.order.line` - categorizing all lines according to a unique set of properties that entirely define the tax and totals computations, compute totals for one sample line and push the result on the whole set. 3/ Recompute totals for subscriptions Quite simple since all underlying data was computed in the previous step, unless round globally is active in the db, can most probably be summed in SQL from the lines directly. Task-1974609
The wording for a financial reporting date option has been clarified so users better understand what the "normal" setting means. This helps avoid confusion with strict date range behavior when configuring or reviewing account reports.
Original PR description
Just to make it clear that it's not equivalent to strict_range.