- Create a report to show price on each template
--> Issue: The price is the same
closesodoo/odoo#78870
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Steps to reproduce the bug:
- Go to purchase > Configuration > Vendor Pricelists
- Filters > select the “Active” filter
Problem:
Currently, the filter does not include records that do not have a specified `”date_end”`, even though they are considered active.
Opw-2659829
closesodoo/odoo#78643
X-original-commit: bb8bef5cff3b67e42218469e898f2b95e4ab315d
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Djamel Touati <DjamelTouati@users.noreply.github.com>
If `_name_search` is called with `limit=None` it could take time in the loop
because `_name_search` for `product.product` has `limit=100`, i.e. it could be
100 iterations to scan 10 K products. To solve this problem, call `_name_search`
with `limit=None` to get all product variants at once.
As an example, the problem is reproduced on using menu `Manufacturing > Products
> Bills of Materials`, which makes following search query:
```
["|", ["code", "ilike", "XXX"], ["product_tmpl_id", "ilike", "XXX"]]
```
for which ORM calls `_name_search`:
https://github.com/odoo/odoo/blame/9b23864027bc24032993833f213395cb45fe86bb/odoo/osv/expression.py#L863
In a customer database, this speeds up the query from 70 seconds to 3,5 seconds.
---
opw-2631012
closesodoo/odoo#77601
X-original-commit: 038816725a988a0ada3d6f8518a436ea46a81eba
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>
The combination of a RR and a supplier that has a minimum quantity and a
lead time leads to incorrect results
To reproduce the issue:
1. Create a product P:
- Type: Storable
2. Add a reordering rule for P (min: 10, max: 50)
3. Add a vendor to P
- Quantity: 1
- Price: 1
- Delivery Lead Time: 7
4. Run the scheduler
5. Open the generated PO
Error: The order deadline is <today minus 7 days> instead of today. The
receipt date is today instead of <today plus 7 days>
When computing the quantity to order, the method needs the value of
`qty_forecast` (L254 in [1]) The computation of `qty_forecast` leads to
the computation of `lead_days_date`. To do so, it gets the lead days of
the associated stock rule `_get_lead_days`. In this method, a seller is
selected: [2] However, none of the parameter is defined: [3]
In the above case, the seller has a minimum quantity of 1. Therefore,
since this information is not given in [2], the vendor is not selected
and his lead time is therefore not taken into account. So,
`lead_days_date` will be equal to 0 and won't be recomputed. As a
result, the planned delivery date is today. Then, the quantity to order
is computed (L260 in [1]), so later, the module is able to select the
correct seller. However, this one has a lead time of 7 days -> the
generated PO will have the planned date to today and the order deadline
to <today minus 7 days>
Once an orderpoint has its quantity to order defined, its lead time
should be recomputed because it may be different depending to the
selected seller (and thus we should take this quantity into account when
searching for a seller)
[1]
https://github.com/odoo/odoo/blob/59ac8d891de6e20604494d6cfc6fc357a88d226c/addons/stock/models/stock_orderpoint.py#L254-L260
[2]
https://github.com/odoo/odoo/blob/1b03087524080f1a9751b1561cd8891466e72367/addons/purchase_stock/models/stock_rule.py#L153
[3]
https://github.com/odoo/odoo/blob/045c6ad3353bb0849d3f93d3488d8dcd8b8975b0/addons/product/models/product.py#L602
OPW-2614798
closesodoo/odoo#77110
X-original-commit: f2eb1dca99d16d70613c2f724d4b73f273a49ae7
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Commit fa034b2a64 removed lst_price on
product.template That means we need to check if product is a variant or
not to choose the suitable price field.
closesodoo/odoo#76503
X-original-commit: c50e7b106b08577228a410e1e34403bd8a6eb80d
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Several changes distinguish product attributes better from variant
attributes. The variant creation mode is added on the template form for
attribute lines with more than one value. Specification attributes are
no longer listed as variant attributes in the product variant form and
tree views.
task-2466988
closesodoo/odoo#72559
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Co-authored-by: Tom De Caluw <tdc@odoo.com>
Co-authored-by: Jeremy Kersten <jke@odoo.com>
Description of the issue/feature this PR addresses:
Currently, we cannot display prices per unit (for example $/kg, etc.)
on products shown in the shop. This is important for any eCommerce
business that sells something other than units, or just for informational
purposes.
Desired behavior after PR is merged:
Allows the user to add unit measurements for products. This behaviour is
disabled by default, and can be enabled through the settings page by
activating "eCommerce Base Unit Price" option.
Enabling it displays a price per unit field in /shop's product page,
comparison tool and cart. The price per unit of measurement is
automatically computed and can be displayed both on the product,
the cart and the comparison pages.
Enabling it also modifies the product's configuration page to include
what unit of measure to display in the price per unit field, as well
as the number of units used to calculate the price per unit.
task-2558128
Part-of: odoo/odoo#72242
Co-authored-by: Kamen Zhekov <kzh@odoo.com>
Co-authored-by: Jeremy Kersten <jke@odoo.com>
This commit removes the pdf and zpl reports for product templates and
variants. Instead, labels are printed via a new wizard allowing to
specify the label quantity, format and optional text.
There are a bunch of usual retail label sizes in pdf or zpl code
Task : 2501730
closesodoo/odoo#69690
Related: odoo/enterprise#20246
Related: odoo/upgrade#2542
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Improve the UI for the MO and the WO with some new features, better readability and usability
- The forecast for the MO in draft makes the preparation of a MO easier. The behavior of `forecast_availability` depend of the state of the move
- The sum of expected duration and real duration in the MO, make the MO visually clearer
- The field Scheduled Date is rounding up to the next hour for less manipulation
- The automatic reference in a BOM if there is already a BOM for this product allows making less manipulation. I'm using this variable `number_of_bom_of_this_product` with the result of the query inside so I didn't need to do the query twice and the query doesn't take the current bom.
- A rounded value is better for the OEE in WO summary
- Have a tag for a workcenter can be a good idea to add more information to it. I'm using a random value for the color of the tag, we are doing it frequently to have a random color on multiple think.
- Knowing the final product of a WO is clearer
- To notify the user when creating a product with a reference that are already existing is a good idea.
- Change some color in the MO view for better readability
- And more minor tweak (like to align some part in the view)
--- Links ---
The PR: https://github.com/odoo/odoo/pull/74540
The PR on enterprise: https://github.com/odoo/enterprise/pull/20006
Task related: 2442895
closesodoo/odoo#74540
Related: odoo/enterprise#20006
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
PURPOSE
Display the color of the attribute value on the product kanban card
SPECIFICATION
Add color field for models `product.attribute.value` and
`product.template.attribute.value`.
Task-2593655
closesodoo/odoo#74356
Related: odoo/enterprise#20048
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
* Linting, typos & cleanup
* Avoid using the context to pass data to the server
* JS: let the web client service manage the data transfer
instead of "manually" specifying it in the report_name
closesodoo/odoo#73198
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
PURPOSE
------
In the new pricelist report, showing the resulting price of a product in the
situation of a pricelist or another, for certain quantities, the specified
quantities are shown as "X Units".
This can be misleading when using multiple Unit of Measure, because
the quantites are expressed in the products unit of measures, thus
not always in "Units".
We should probably either group the products by UoM, to display
adequates column titles, or we should update the display to make sure the user
understands clearly that the prices are /unit in the product uom.
users should be able to 'hide' pricelist name on the PDF.
TaskID-2360597
New reception report added for non-outgoing transfers. This is intended
to support easier stock allocations by allowing dynamic MTO
assignment/unassignment, e.g. if we have an incoming transfer with
products we want to assign to an existing outgoing transfer, then we can
use the report to create a MTO link to the specific outgoing moves. To
support this assignment flow, the report also allows printing of labels
to place on the product so stock workers know which transfer/MO the
product has been assigned to.
Expected use case is when a product is purchased to fulfil a sale.
Demo data has been added so reception report can be immediately
seen/used for this flow.
Implementation Notes:
- Report has been made flexible to work with batch transfers.
- Only done moves can be assigned to moves that already have quants
reserved (prevents undesired behavior + this makes sense logically)
- Confirmed (+ Done and everything inbetween) moves can be assigned to
any confirmed moves that are not already assigned.
- Report does not affect quant reservation/unreservation at all. It
works only with linking moves (i.e. move_orig_id/move_dest_id) so
move/transfer linkage traceability is stored within db (i.e. this
isn't possible with quants)
Limitations: To keep code simple for now, this assignment flow will
break in certain cases:
1. Done amount of an assigned move is less than the Demand amount
(linked move will not autoreserve correctly when assigned move is
validated, same issue already occurs in multi-step transfer).
2. If a linked move is unreserved after its assigned move is
validated, then another move can reserve its quants and its
assignment link will not be accurate.
3. Already reserved SNs + assign move, may lead to mismatching SNs
between report and what's actually reserved.
4. Changing a linked move's Demand amount after a move is assigned to
it.
5. Potential moves to assign to are only checked for being in same
warehouse, not in a matching source location to destination location.
User is expected to make this match on their own.
Task: 2500844
ENT PR: odoo/enterprise#18268
Upgrade PR: odoo/upgrade#2731closesodoo/odoo#70669
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Automatically activate `group_multi_currency` if there is more than one active currency,
deactivate it if there is only one active currency
retain sale/pos feature of activating group_product_pricelist
adapt tests accordingly
Task 2610735
closesodoo/odoo#74396
Related: odoo/enterprise#20106
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Users will now have a quick way to add images on their products in batches, allowing fast visual identification of them.
task-2518519
closesodoo/odoo#70198
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
Excluding non-active records decreases number of combinations generated in
_cartesian_product. The excluded combinations have to be rejected anyway [1], so
don't waste time on it.
STEPS:
* activate "Product Configurator"
* create a product with many attributes
* make some `product.template.attribute.value` inactive (ptav_active = False):
** create a sale order with that value (e.g. color "Black" in "Customizable Desk (CONFIG)")
** delete that value in `product.template` form (tab "Variants")
* add the product to a sale order
* RESULT: `_cartesian_product` doesn't generates combination with archived attribute
[1]
https://github.com/odoo/odoo/blob/f9d26509a714ecd290c42e1d58e416bb01268447/addons/product/models/product_template.py#L839-L841
---
opw-2540675
closesodoo/odoo#74310
X-original-commit: ce487c920c777735e5e7e46ee131cb18dfc5c9fc
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>
The license is missing in most enterprise manifest so
the decision was taken to make it explicit in all cases.
When not defined, a warning will be triggered starting from
14.0 when falling back on the default LGPL-3.
closesodoo/odoo#74245
Related: odoo/design-themes#48
Related: odoo/enterprise#19862
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Currently, pricelists can be deleted even if a pricelist rule uses this pricelist as base.
This leads to an error when the rule is used because it tries to access a deleted record.
This commit restricts the deletion of such pricelists, avoiding later tracebacks.
closesodoo/odoo#73907
X-original-commit: 8c3c7d9e85ca4353d3b8501cc5c484a3bd955754
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Co-authored-by: vfe-odoo <Feyensv@users.noreply.github.com>
Re-introduce after discussion with AL the function that allow to specify
a custom placeholder for a specific model.
It has been removed because no more used since we use avatar mixin for
res.users and res.company. But it doesn't means that each model should add
his own mixin and controller and ... Keep it simple!
Use it for product and product template to have a default placeholder more
representative of the model.
Courtesy of xlu-odoo for this design
opw-2513801
closesodoo/odoo#73576
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Steps to reproduce:
- Create a new pricelist;
- In the Price Computation, select "Formula" then
change it to "Based on Cost";
- Change the price computation back to "Percentage (discount);
- Create a sale and set this new pricelist.
Issue:
Price discount made on the cost of the product instead to get back
to sale price as default
Cause:
When switching `Compute Price` and != 'formula', not setting back
`Based on` (base) to `Public Price` (list_price).
Solution:
If compute_price is changed and new value != 'formula'; set
pricelist `Based on` to `Public Price`.
opw-2587295
closesodoo/odoo#73263
X-original-commit: 3f409c08723827766db4b3f40d7777f485e78230
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
Before this commit, suppose we have a scenario like below
Task-A:
Activity-1:
name: Email ( Today )
Assigned to: User-1
Task-B:
Activity-1:
name: Email ( Today )
assigned to: User-2
Activity-2:
name: Call ( Due in 3 Days )
assigned to: User-1
When User-1 goes through the systray 'Today' filter shortcut he gets both
Task-A and Task-B in the list instead of only Task-A. Indeed currently
activities are not filtered based on current user with its deadlines.
However purpose of systray is to indicate activities current user has to
perform instead of global activities.
After this commit activities will be filtered based on deadlines as well as the
current user. In order to achieve this behavior we needed to pass a domain like
[
('activity_ids.date_deadline','=', fields.Date.today()),
('activity_ids.user_id','=', 1)
]
And for that purpose we introduced a non-stored compute field with a search
method.
Task ID-2438822
COM PR odoo/odoo#72219
X-original-commit: f4eaf4d8fb2f97240201104dcd4fc7e2674bce02
This commit splits the 'getActionManagerTestConfig' helper into 2:
'setupWebClientServiceRegistry' and 'getActionManagerServerData'.
The first one is now automatically called by the 'createWebClient'
helper, as it properly setups the service registry with all services
required by the WebClient component.
The second one generates a few data (menus, actions, views...) that
can be used in tests. That helper is mainly useful for action tests
(formerly ActionManager tests) in web. With this refactoring, they
are no longer generated for each test in the whole codebase that
spawns a webclient, as before this commit.
closesodoo-dev/odoo#906
Related: odoo-dev/enterprise#161
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
This commit adapts the community codebase to the rewriting of the
/web application in owl.
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
Co-authored-by: Géry Debongnie <ged@odoo.com>
Co-authored-by: Samuel Degueldre <sad@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Simon Genin (ges) <ges@odoo.com>
Co-authored-by: Francois (fge) <fge@odoo.com>
Co-authored-by: Michael Mattiello (mcm) <mcm@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Lucas Perais (lpe) <lpe@odoo.com>
Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com>
Before this commit, products relying on values of template fields (i.e.
image) were not considered updated when their fallback template field
was updated.
After this commit, upon update of a template image, all products that
would fallback on that template are "touched".
This avoids side-effects such as displaying an outdated template image
in the e-commerce for a given product.
task-2477438
closesodoo/odoo#71139
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
It replace text fields to html fields as we have our own 'OdooEditor'.
Indeed, it gives more options to users in the way they format their
content without weighting too much on the UI
(tools appear on demand and not by default).
Models -> Fields
1) sale.order -> note
2) sale.order.template -> note
Task Id: 2499504
X-original-commit: 6a345c2695129a5cd907e5e23e057871ebf9ebfa
- Rename Priority to Favorite
- Move the priority field star icon in the kanban view
- Remove the sequence field from the list view
- (website_sale) make the favorite column optional in tree view
- (website_sale) keep same order in kanban view than in list view
task-2496758
closesodoo/odoo#69657
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Regarding of the `display_default_code` context value, `display_name` is
supposed to return the product code or not, eg:
> product.display_name
> '[FURN_6666] Acoustic Bloc Screens'
> product.with_context(display_default_code=False).display_name
> 'Acoustic Bloc Screens'
But since the context was not considered when accessing this field, it would
always return the cached value, which was set from the first time that field
was read, with the `display_default_code` value used at that time.
tl;dr: `display_name` was ignoring the context once cached.
One of the critical issue was that internal code were displayed on the eshop
cart (not the eshop itself), see `name_short`.
task-2517830
closesodoo/odoo#70739
X-original-commit: b5b4d38adf1f3960cda21b795a26e67b978b2901
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
1. add packaging to PO lines
2. packaging on PO/SO lines can be propagate to MO
3. add package type to packaging
4. on picking types, we can choose to only reserve full packaging. That
means if you want 1 pallet(100 units) and you have 50 units in stock. It
won't be reserved.
5. suggest suitable packaging for PO/SO/MO line according to the product
qty
Task-2357259
PR #68654
UPG PR odoo/upgrade#2444
The attributes field.depends and field.depends_context are problematic
for sharing fields across registries, because they depend on the model's
registry class, which may vary from one registry to another. In order
to make computed fields shareable, we have to move those values away
from fields.
For the same reason, field.recursive should not be inferred, because its
value may depend on the registry, although it is generally not the case.
Moreover, the flag recursive=True is set on a field when field triggers
are determined (on the registry). A compute method may be called before
the flag is set (if no update has been done yet), and that can lead to
incorrect computations.
This happened in test TestUsers2.test_reified_groups in module 'base'.
The user groups view was apparently determined without the flag being
set, and the view depends on the recursive field 'trans_implied_ids',
which was not correctly computed.
We thus force developers to be explicit about recursive computed fields.
The code now logs a warning when the flag is not set up properly.
- Improve product.product & product category population: Add "random"
types, prices, and product categories to product. Specify some product
categories as children of others (populate the `parent_id` field).
- Provide product template and product attributes population
- product pricelist population
task-2446266
Co-authored-by: Feyensv <vfe@odoo.com>
*: portal, portal_rating, product, sale, sale_product_configurator,
website, website_sale_comparison, website_sale_product_configurator,
website_sale_stock, website_sale_wishlist, point_of_sale
Redesign of the product page + various UX improvements.
task-2009483
Part of #66736
Conversion of all modules to the new manifest assets declaration.
Part of task: 2352566
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Simon Genin <ges@odoo.com>
The compute of `product_variant_count` was highly inefficient
in batch. It is due to `with_prefetch` which remove the prefetch
(reset _prefetch_ids = _ids) of the for loop.
It was added by 05a00fa9d4
which fixed performance issue for the 11.0 about
`sales_count`. But with the new ORM (13.0) compute fields are lazy.
Performance improvements:
For the search_read of the kanban view (Menu: Sale/Products/Products)
with the default pagination (80 items):
Before: 347 SQL request and 0.31 +- 0.2 sec (Python and SQL time)
After: 110 SQL request and 0.14 +- 0.2 sec (Python and SQL time)
task-2439019
Purpose of the task is, 'general setting' is not easily understandable
by the user. The user often gets lost. This is especially damaging
through onboarding as some new users like to discover the software by
scrolling through the general settings.
So in this commit, the general setting is well organized and easily
understandable by the user.
Related PR: https://github.com/odoo/enterprise/pull/14707closesodoo/odoo#61645
Taskid: 2374990
Related: odoo/enterprise#14707
Related: odoo/upgrade#1958
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Florent de Labarre