Daily updates from Odoo
Thursday, August 1, 2019
14 changes · master
New functionality added to Odoo
Work order tablet users can now view embedded Google Slides directly in the manufacturing interface. The slide viewer stays open without reloading when actions are performed, making instructions easier to follow and reducing interruptions on the shop floor.
Original PR description
task ID : https://www.odoo.com/web?#id=1909010&action=333&active_id=131&model=project.task&view_type=form&menu_id=4720
Enhancements to existing features
Purchase order lines now automatically use the planned date entered on the purchase order, helping buyers keep delivery schedules consistent without manually updating each line. The old bulk date button is removed, and line dates remain editable only when no overall planned date is set.
Original PR description
task : https://www.odoo.com/web#id=2032417&action=333&active_id=966&model=project.task&view_type=form&menu_id=4720 pad : https://pad.odoo.com/p/r.fda3cacae6d8e949acc4f90f7f444fda 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
Manufacturing teams can now display Google Slides directly inside work center and work order screens. This makes it easier for shop floor users to view instructions or supporting materials without leaving Odoo.
Original PR description
Description of the issue/feature this PR addresses: task: https://www.odoo.com/web?#id=1909010&action=333&active_id=131&model=project.task&view_type=form&menu_id=4720 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
This update makes the system logging screens easier to read and use by removing clutter, improving layout, and dropping search options that did not provide value. It helps administrators review log information more efficiently without changing the underlying logging behavior.
Original PR description
Description of the issue/feature this PR addresses: The `ir.logging` views are not structured, miss elements and have not needed values. Current behavior before PR: - The tree view shows literally…
Description of the issue/feature this PR addresses: The `ir.logging` views are not structured, miss elements and have not needed values. Current behavior before PR: - The tree view shows literally all fields making it a cluttered view. - The search view has empty domains set which add no value. - The form view misses the `<sheet>` parameter, was badly layouted and had no group name/strings or logic. Desired behavior after PR is merged: - Clean tree view. Before:  After:  - The search view no longer has empty and non-usable domains - The form view has the `<sheet>` parameter and is now nicely layouted. It also has two groups with names for clean xpaths and data separation. Before:  After:  - The XML file is nicely formatted and indented -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update removes obsolete references to deprecated API decorators from the developer documentation. It helps keep guidance accurate and reduces confusion for teams maintaining or extending Odoo.
Original PR description
Those two decorators are removed/deprecated since recent commits but some references remained in the documentation. api.guess and api.noguess is deprecated and removed since https://github.com/odoo/odoo/commit/c552fb7a618afe2feea2e0358ead9eb6ebff0c94 **Current behavior before PR:** Outdated decorators **Desired behavior after PR is merged:** No longer the outdated decorators -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update refreshes Luxembourg accounting templates to align with the 2020 standard chart of accounts and replaces the older monthly VAT report with the latest version. It helps Luxembourg companies use more current statutory accounting and tax reporting structures, with English as the base language and French and German translations included.
Original PR description
- Update the CoA for 2020 - Add the most recent monthly tax report instead of the old one with the new tax model - Base language English (multilang translation in fr and de) hsh and rgo co-authored opw-1917932 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 purchasing product form now uses a clearer “Vendor Prices” section name and allows vendor price lines to be edited more easily with dropdown field selection. This should make purchase onboarding and vendor pricing setup simpler for users.
Original PR description
**Description of the issue/feature this PR addresses:** Task:https://www.odoo.com/web#id=2029380&action=327&model=project.task&view_type=form&menu_id=4720 Pad:https://pad.odoo.com/p/r.033eca3b9e0fa87a4c631c82ba21fcf9 **Description** Made tree view of vendors editable and added dropdown to select fields. Modified section name in purchase tab on product form. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Shortcut buttons on records were standardized across several Odoo apps so they behave more consistently. This helps users navigate related information with clearer context and avoids creating related records where it should not be allowed.
Original PR description
Pad:https://pad.odoo.com/p/r.a539473706deabca72f72e98f60b751f Task::https://www.odoo.com/web?debug=assets#id=2024467&action=333&active_id=967&model=project.task&view_type=form&menu_id=4720
Odoo removes the old customer and supplier labels from contacts so users can find the right partner when creating documents. This reduces confusion and duplicate contacts while updating related business apps to keep partner choices relevant.
Original PR description
Purpose ======= Fields `customer` and `supplier` on `res.partner` are mostly used in domains of many2x fields. Those domains can confuse end users because they don't see the partner they are looking for; and it's not obvious why. This can lead to duplicated partners: the user does not find one, so he creates a new one. Specification ============= Adapt Enterprise modules for removal of the mentioned fields. Community PR: https://github.com/odoo/odoo/pull/34524 Task: 2031147
Resolved issues and error corrections
This update adjusts how average product costs are calculated so small currency rounding differences are reduced. It helps keep inventory valuation and invoice-related accounting amounts more consistent, especially in Anglo-Saxon accounting flows.
Original PR description
Since the introduction of the stock valuation layer, unit_cost is rounded in the company currency (actually it is NOT because of an ORM bug that will be fixed later). With the test introduced at [0], fixing that ORM bug shows we have a rounding issue (27.02 instead of 27) due to the company currency rounding on the unit_cost. Since the logic of the anglo saxon will probably always give some rounding issue (we always return a price unit that will be multiply by the invoiced quantity) recomputing a not rounded price unit by using the not rounded value with the not rounded quantity seems a good enough compromise. [0] 13a535a0918f6f75d8c631a465fbc9238ea954bf
Odoo now keeps translation source text in sync automatically instead of storing a separate outdated source field. This improves consistency when records are edited in single-language or multi-language databases, reducing cases where users could still see old translated values after an update.
Original PR description
Instead, make sure the field src is always up to date Change a bit the behaviour of `_write` to always try to update potential translations when in monolanguage (was only done in multi-language if different than en_US) and always create translations when writing on a translatable field when in multi-language (was skipped in en_US) Add tests Task-id: 2031752 Pad: https://pad.odoo.com/p/r.dbf835d0aae979d858f73446dcbfb1df
Restores a planning date used by the manufacturing master production schedule to decide whether a purchase order already covers a need. This helps avoid unnecessary duplicate purchase orders after a related purchasing logic change.
Original PR description
Community changed the logic of date_planned on the PO but mrp_mps still needs the original to know if it should create a new po or not. Reintroduce the needed field. task-2032417
Features or functions removed from Odoo
Odoo removes the customer and supplier checkboxes from contacts so users can find any partner when creating sales, purchases, invoices, and related records. Search results are now ranked by existing sales or purchase activity, helping users pick the most relevant customers or suppliers without accidentally creating duplicates.
Original PR description
1/ Improve res.partner search for customers/suppliers ========================================= Purpose ------- This commit allows to call `name_search` with context key `res_partner_search_mode`…
1/ Improve res.partner search for customers/suppliers
=========================================
Purpose
-------
This commit allows to call `name_search` with context key
`res_partner_search_mode` that can take currently two values: "customer" or
"supplier".
When ordering search results, order partners by the number of SO they have when
the value is "customer" and by the number of PO if the value is "supplier".
Top suppliers/customers are displayed above in a PO/SO partner dropdown.
We have thought about different implementations before selecting this one:
- Keep the 2 boolean flags and automatically set them if a SO or PO is created
for a customer/supplier (helps a bit but doesn't work well for the first
SO/PO). As the onboarding is also a priority, we didn't implement it.
- Instead of filtering on the bool flags, sort the name_search() result according
to the number of orders they already have (e.g. if you search for "Foo" on a
PO, a supplier "SuperFoo" with 32 purchase orders will appear before supplier
"HorribleFoo" that has no PO). Problem is to do this in an efficient manner for
large databases - possibly we could store a "relevance index" based on the
number
of recent orders. Storing those values is an issue too, as it doesn't work well
for multi company database. Indeed, storing values that depend on the context
is certainly not a good idea.
- Same as previous alternative but with no stored columns, rather a JOIN in
name_search. This is the solution that have been kept. The only concern was
about the perfomances. We tested it on our production base, on a sales order,
as we have way much more customers than suppliers. After a deep analysis on
the querry and the bitmap generated by PostgreSQL, we can conclude that the
count(*) works rather efficiently and that the request is not significantly
heavier than without the context key.
Performance Analysis
--------------------
The following results have been obtained on our production database.
### Before this commit ###
The original query is the following one:
```
EXPLAIN ANALYSE
SELECT res_partner.id
FROM "res_partner"
WHERE ("res_partner"."customer" = True) AND ("res_partner"."active" = True) AND ((("res_partner"."type" != 'private') OR "res_partner"."type" IS NULL) OR "res_partner"."type" IS NULL ) AND (res_partner.email ilike '%eezee-i%'
OR res_partner.display_name ilike '%eezee-i%'
OR res_partner.ref ilike '%eezee-i%'
OR res_partner.vat ilike '%eezeei%')
-- don't panic, trust postgres bitmap
ORDER BY res_partner.display_name ilike '%eezee-i%' desc,
res_partner.display_name
limit 8;
```
Here is the EXPLAIN ANALYSE returned by PostgreSQL:
```
Limit (cost=1625.50..1625.52 rows=8 width=21) (actual time=13.397..13.404 rows=8 loops=1)
-> Sort (cost=1625.50..1626.32 rows=326 width=21) (actual time=13.395..13.396 rows=8 loops=1)
Sort Key: (((display_name)::text ~~* '%eezee-i%'::text)) DESC, display_name
Sort Method: top-N heapsort Memory: 26kB
-> Bitmap Heap Scan on res_partner (cost=1282.79..1618.98 rows=326 width=21) (actual time=13.025..13.350 rows=56 loops=1)
Recheck Cond: (((email)::text ~~* '%eezee-i%'::text) OR ((display_name)::text ~~* '%eezee-i%'::text) OR ((ref)::text ~~* '%eezee-i%'::text) OR ((vat)::text ~~* '%eezeei%'::text))
Rows Removed by Index Recheck: 1
Filter: (customer AND active AND (((type)::text <> 'private'::text) OR (type IS NULL) OR (type IS NULL)))
Rows Removed by Filter: 1
Heap Blocks: exact=58
-> BitmapOr (cost=1282.79..1282.79 rows=328 width=0) (actual time=12.983..12.983 rows=0 loops=1)
-> Bitmap Index Scan on res_partner_name_tgm_idx_gin (cost=0.00..322.22 rows=162 width=0) (actual time=5.022..5.022 rows=54 loops=1)
Index Cond: ((email)::text ~~* '%eezee-i%'::text)
-> Bitmap Index Scan on res_partner_name_tgm_idx_gin (cost=0.00..322.22 rows=162 width=0) (actual time=4.128..4.128 rows=56 loops=1)
Index Cond: ((display_name)::text ~~* '%eezee-i%'::text)
-> Bitmap Index Scan on res_partner_name_tgm_idx_gin (cost=0.00..321.00 rows=1 width=0) (actual time=2.240..2.240 rows=0 loops=1)
Index Cond: ((ref)::text ~~* '%eezee-i%'::text)
-> Bitmap Index Scan on res_partner_name_tgm_idx_gin (cost=0.00..317.03 rows=4 width=0) (actual time=1.585..1.585 rows=0 loops=1)
Index Cond: ((vat)::text ~~* '%eezeei%'::text)
Planning time: 0.766 ms
Execution time: 13.489 ms
```
### After this commit ###
Without the context key, the query looks like this:
```
SELECT res_partner.id
FROM "res_partner"
WHERE ("res_partner"."active" = True) AND ((("res_partner"."type" != 'private') OR "res_partner"."type" IS NULL) OR "res_partner"."type" IS NULL ) AND (res_partner.email ilike '%eezee-i%'
OR res_partner.display_name ilike '%eezee-i%'
OR res_partner.ref ilike '%eezee-i%'
OR res_partner.vat ilike '%eezeei%')
-- don't panic, trust postgres bitmap
GROUP BY res_partner.id
ORDER BY COUNT(*) DESC, res_partner.display_name ilike '%eezee-i%' desc,
res_partner.display_name
limit 8;
```
And it quite clear when looking at the EXPLAIN ANALYSE that the request
is quite the same, except the aggregation that is made with a quicksort method.
```
Limit (cost=1645.00..1645.02 rows=8 width=29) (actual time=13.200..13.206 rows=8 loops=1)
-> Sort (cost=1645.00..1645.82 rows=328 width=29) (actual time=13.197..13.198 rows=8 loops=1)
Sort Key: (count(*)) DESC, (((display_name)::text ~~* '%eezee-i%'::text)) DESC, display_name
Sort Method: top-N heapsort Memory: 26kB
-> GroupAggregate (cost=1631.88..1638.44 rows=328 width=29) (actual time=13.090..13.160 rows=56 loops=1)
Group Key: id
-> Sort (cost=1631.88..1632.70 rows=328 width=20) (actual time=13.080..13.084 rows=56 loops=1)
Sort Key: id
Sort Method: quicksort Memory: 29kB
-> Bitmap Heap Scan on res_partner (cost=1282.79..1618.17 rows=328 width=20) (actual time=12.793..13.055 rows=56 loops=1)
Recheck Cond: (((email)::text ~~* '%eezee-i%'::text) OR ((display_name)::text ~~* '%eezee-i%'::text) OR ((ref)::text ~~* '%eezee-i%'::text) OR ((vat)::text ~~* '%eezeei%'::text))
Rows Removed by Index Recheck: 1
Filter: (active AND (((type)::text <> 'private'::text) OR (type IS NULL) OR (type IS NULL)))
Rows Removed by Filter: 1
Heap Blocks: exact=58
-> BitmapOr (cost=1282.79..1282.79 rows=328 width=0) (actual time=12.755..12.755 rows=0 loops=1)
-> Bitmap Index Scan on res_partner_name_tgm_idx_gin (cost=0.00..322.22 rows=162 width=0) (actual time=4.823..4.823 rows=54 loops=1)
Index Cond: ((email)::text ~~* '%eezee-i%'::text)
-> Bitmap Index Scan on res_partner_name_tgm_idx_gin (cost=0.00..322.22 rows=162 width=0) (actual time=3.941..3.941 rows=56 loops=1)
Index Cond: ((display_name)::text ~~* '%eezee-i%'::text)
-> Bitmap Index Scan on res_partner_name_tgm_idx_gin (cost=0.00..321.00 rows=1 width=0) (actual time=2.186..2.186 rows=0 loops=1)
Index Cond: ((ref)::text ~~* '%eezee-i%'::text)
-> Bitmap Index Scan on res_partner_name_tgm_idx_gin (cost=0.00..317.03 rows=4 width=0) (actual time=1.798..1.798 rows=0 loops=1)
Index Cond: ((vat)::text ~~* '%eezeei%'::text)
Planning time: 0.761 ms
Execution time: 13.317 ms
```
With the context key, the query looks like this:
```
EXPLAIN ANALYSE
SELECT res_partner.id
FROM "res_partner"
LEFT JOIN sale_order ON res_partner.id = sale_order.partner_id
WHERE ("res_partner"."active" = True) AND ((("res_partner"."type" != 'private') OR "res_partner"."type" IS NULL) OR "res_partner"."type" IS NULL ) AND (res_partner.email ilike '%eezee-i%'
OR res_partner.display_name ilike '%eezee-i%'
OR res_partner.ref ilike '%eezee-i%'
OR res_partner.vat ilike '%eezeei%')
-- don't panic, trust postgres bitmap
GROUP BY res_partner.id
ORDER BY COUNT(*) DESC, res_partner.display_name ilike '%eezee-i%' desc,
res_partner.display_name
limit 8;
```
The only difference is that a nested loop is made for the left join, as postgreSQL has
correctly identified the dicriminating table. The correct result is obtained within
a similar duration.
```
Limit (cost=2700.68..2700.70 rows=8 width=29) (actual time=12.561..12.568 rows=8 loops=1)
-> Sort (cost=2700.68..2701.50 rows=328 width=29) (actual time=12.559..12.560 rows=8 loops=1)
Sort Key: (count(*)) DESC, (((res_partner.display_name)::text ~~* '%eezee-i%'::text)) DESC, res_partner.display_name
Sort Method: top-N heapsort Memory: 26kB
-> GroupAggregate (cost=2687.56..2694.12 rows=328 width=29) (actual time=12.449..12.527 rows=56 loops=1)
Group Key: res_partner.id
-> Sort (cost=2687.56..2688.38 rows=328 width=20) (actual time=12.408..12.425 rows=305 loops=1)
Sort Key: res_partner.id
Sort Method: quicksort Memory: 42kB
-> Nested Loop Left Join (cost=1283.21..2673.86 rows=328 width=20) (actual time=11.629..12.340 rows=305 loops=1)
-> Bitmap Heap Scan on res_partner (cost=1282.79..1618.17 rows=328 width=20) (actual time=11.596..11.862 rows=56 loops=1)
Recheck Cond: (((email)::text ~~* '%eezee-i%'::text) OR ((display_name)::text ~~* '%eezee-i%'::text) OR ((ref)::text ~~* '%eezee-i%'::text) OR ((vat)::text ~~* '%eezeei%'::text))
Rows Removed by Index Recheck: 1
Filter: (active AND (((type)::text <> 'private'::text) OR (type IS NULL) OR (type IS NULL)))
Rows Removed by Filter: 1
Heap Blocks: exact=58
-> BitmapOr (cost=1282.79..1282.79 rows=328 width=0) (actual time=11.560..11.560 rows=0 loops=1)
-> Bitmap Index Scan on res_partner_name_tgm_idx_gin (cost=0.00..322.22 rows=162 width=0) (actual time=4.724..4.724 rows=54 loops=1)
Index Cond: ((email)::text ~~* '%eezee-i%'::text)
-> Bitmap Index Scan on res_partner_name_tgm_idx_gin (cost=0.00..322.22 rows=162 width=0) (actual time=3.825..3.825 rows=56 loops=1)
Index Cond: ((display_name)::text ~~* '%eezee-i%'::text)
-> Bitmap Index Scan on res_partner_name_tgm_idx_gin (cost=0.00..321.00 rows=1 width=0) (actual time=1.752..1.752 rows=0 loops=1)
Index Cond: ((ref)::text ~~* '%eezee-i%'::text)
-> Bitmap Index Scan on res_partner_name_tgm_idx_gin (cost=0.00..317.03 rows=4 width=0) (actual time=1.254..1.254 rows=0 loops=1)
Index Cond: ((vat)::text ~~* '%eezeei%'::text)
-> Index Only Scan using sale_order_partner_id_index on sale_order (cost=0.42..2.74 rows=48 width=4) (actual time=0.006..0.007 rows=5 loops=56)
Index Cond: (partner_id = res_partner.id)
Heap Fetches: 12
Planning time: 1.056 ms
Execution time: 13.791 ms
```
2/ Remove customer and supplier fields from res.partner
===========================================
Purpose
-------
Fields `customer` and `supplier` on `res.partner`
are mostly used in domains of many2x fields.
Those domains can confuse end users because they don't
see the partner they are looking for; and it's not obvious why.
Some identified problems:
1. It can lead to duplicated partners: the user does not find
the partner, so he creates a new one.
2. The user imports supplier contacts in the Contacts app, so they
don't get the `supplier` flag. Then the user wants to make a purchase order,
and cannot find the new suppliers in the list
3. A user removes the customer flag on a prospect, because they don't think
it's a customer yet - except now they can't make a quote for that customer...
Specification
-------------
Remove the two mentioned fields.
Since fields `customer` and `supplier` have been removed, all partners
are now shown in many2one dropdowns.
But in some cases, not all partners are relevant or some are more likely
to be relevant than others. e.g. when creating a PO, top suppliers have a
higher priority than other partners.
So, adapt the places where those fields were used with the new mechanism to
display the searched the partners, according to the number purchase/sales
orders they made.
TaskID: 2031147
Co-authored-by: Yannick Tivisse <yti@odoo.com>This change removes an unused setting from a website menu link. It simplifies the template without changing what users see, because the opened page already applies the intended default filter.
Original PR description
Since this is a website template, the `context` does not make much sense. Additionally, there is no search filter named `web_features`. Lastly, the action opened via this link already has a default search filter enabled [[1]]. [1]: https://github.com/odoo/odoo/blob/81f024b545c8ddeeed040fcde42db3f5f7e2a468/addons/website/views/website_views.xml#L17 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr