This commit converts the report code to the new framework.
Since the module stock still has code that extends the old
"ReportClientAction", the old report code is put inside this module.
It can be then naturally removed once the module is fully converted.
closesodoo/odoo#97390
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Adds a new reporting view for [storable] product.product to allow for
easier analysis by product (rather than by quant which is location
specific).
This includes:
- adding 3 new fields for products:
- avg_cost = total svl value / total qty
- total_value = avg_cost / on hand
- company_currency_id = self.env.company.currency_id (i.e. the
currently selected company) for which currency symbol to display in
the view
- IMPORTANT NOTE:
- these variables (and some of the existing ones) do NOT support
multi-company aggregations due these values being used to calcuate
future svls which should be company specific. Larger refactoring
would be needed to ensure correct calc in both cases. Larger issue
occurs in stock.report which uses these variables in combination
with variables that do take into account multi-company records.
- A customized `SearchPanel` so that a warehouse context can be applied
to the view, rather than a filter. (viewable only when more than 1
warehouse)
"stock report" part of b2b task: 2882539
Part-of: odoo/odoo#97109
Minor UX updates to forecast report:
- add missing space (between # and unit + before |) also removed
superfluous uoms (only need it at the end now that an equation is
displayed)
- move On Hand Value to under product link (+ variants if they exist)
and make it a link to the valuation report of the product(s) in
question
- add link from Quantity on Hand to the locations (i.e. inventory/quants)
report for the relevant product(s). Note that product template was
added to Search in order to support default searching due to
forecasting report structure
- redo the top right forecast values to be On Hand + Incoming - Outgoing
= Forecasted so we provide more explicit and transparent values.
Additionally, these values are made to not display decimal digits if
all of those digits are 0. Note that forecasted values in table are
untouched (i.e. Forecasted Inventory = Forecasted is unchanged and
Forecasted with Pending still shows in table)
Also did some t-esc => t-out replacement and other small cleanup since
templates were already being edited.
"forecasted report" part of b2b task: 2882539
Part-of: odoo/odoo#97109
Note this is specific to the view shown when clicking on
"Reporting > Valuation", but this uses the same 'stock.quantity.history'
wizard and related custom js as "Configuration > Locations > Current Stock"
Minor UX updates to valuation report:
- don't default groupby product
- add filters incoming and outgoing (same logic as stock.move filters)
- replace "Inventory at Date" with "Valuation at Date" where appropriate
(but leave location current stock view untouched)
- create separate view for the valuation report so remaining qty/value
are displayed, but all other svl viewing actions (including the
"Valuation at Date") will remain showing the original qty/value to
support deeper analysis
- don't sum unit_cost when groupby is applied in list view since the
value won't make sense
- add "reference" to svl which is = to stock.move.reference
"valuation" part of b2b task: 2882539
Part-of: odoo/odoo#97109
Inventory report has been updated to have:
- better applicability: report renamed to "Locations" and is only
visible w/Locations, Consignment, or debug mode active
- improved UX: list view rearranged, buttons added, grouping removed,
sums added to bottom of list
- improved quant "Value": instead of the accounting value, this is now
the average unit cost (i.e. sum(valuation layer values)/sum(valuation
layer quantities) per product x on hand qty (of quant).
- single click load for products
- search based on Warehouse option (including storing
location.warehouse_id to avoid overly complex search function)
- always show "Location" column in this view even if multi-locations is
not active
"inventory report" part of b2b task: 2882539
Upgrade PR: odoo/upgrade#3819
Part-of: odoo/odoo#97109
Steps to reproduce:
- Go to stock > Replenishment
- Click on a forecast report widget
- Go back using the browser arrows
-> The page is redirected to another forecast report and the
breadcrumbs are cleared
Cause of the issue:
The forecast report action uses the `window.history.pushState` to
add the active model in the url.
When going back, the new url is the same one but without the active
model.
We can get the correct behavior by doing `window.history.go(-2)` in
the console.
Solution:
Use `history.replaceState` instead
opw-2917725
closesodoo/odoo#96487
X-original-commit: b39dc5488bacb704aaa60f1a502bf005d57f3276
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
* data('bs.popover') is not a jQuery data anymore
-> fetch data from the instance instead.
* use the new class name 'popover-arrow' instead of 'arrow'
* website_forum: offset is not a number anymore
-> Convert to string instead.
* BS5 event listener: 'focus' -> 'focusin'
* use `mouseover` event to show and `mouseout` to hide.
* disable at some point the animation to avoid remaining listener
in the DOM.
Ref:
https://getbootstrap.com/docs/5.1/migration/#popovers
Task ID: 2766483
Part-of: odoo/odoo#95450
The logic not identical in BS4 -> BS5
The color contrast system in BS5 relies on WCAG 2.0 contrast algo.
So color-yiq is converted to color-contrast.
Note that there are some "texts/buttons/other visuals" elements
which will not have the same contrast as before.
$yiq-text-dark and $yiq-text-light are respectively replaced with
$color-contrast-dark and $color-contrast-light.
Note that we had to use '$min-contrast-ratio: 2.2' for .o_tag_color_X badge.
Task ID: 2766483
Part-of: odoo/odoo#95450
Co-authored-by: Stefano Rigano <sri@odoo.com>
This commit makes various adapations in addons with respect to
the introduction of the owl kanban view. Mainly, some selectors
in scss and in tests needed to be adapted. Moreover, in some tests
that we haven't adapted yet, we must ensure that legacy form and
list views are still used (useLegacyViews).
It also contains some adaptations in kanban templates, e.g. the
replacement of moment by luxon, the removal of underscore...
Part-of: odoo/odoo#92475
In some cases, an unexpected line "Undefined" is displayed on the graph
of the Forecasted Report
To reproduce the issue:
1. Create a storable product P
2. Process a receipt R01 with 1 x P
3. Process a delivery D01 with 1 x P
4. Create and confirm a planned receipt R02:
- Scheduled date: In 7 days
- Operations: 1 x P
5. On the form of P, open the On Hand page
6. Back to the form of P, open Forecasted page
Error: An unexpected line "Undefined" is displayed on the graph and is
always equal to zero
Suppose the user does the same as above without the step 5: there won't
be any unexpected line on the graph. Here are the explanations: after
step 3, a quant for P exists and its quantity is zero. So, suppose the
user doesn't open the "On Hand page" and directly opens the Forecasted
Report. Considering its definition:
https://github.com/odoo/odoo/blob/a9dc406b52a3702f6901f686503e8d841f81724e/addons/stock/report/report_stock_quantity.py#L41
Four things happen (we only consider the state `forecast`):
- The SM of R01 is propagated from `today minus 3 months` to `yesterday`
- Same for SM of D01
- The quant is propagated from `today minus 3 months` to `today plus 3
months`
- The SM of R02 is propagated from `in 7 days` to `today plus 3 months`
-> Thanks to the quant, there are some data between `yesterday` and `in
7 days`
Let's now consider the step 5. Opening the page leads to:
https://github.com/odoo/odoo/blob/b22a23435a0cc42b7084ded21dbd4ef3a4a2113e/addons/stock/models/stock_quant.py#L621-L630
where, in `_quant_tasks`, we unlink the zero quants:
https://github.com/odoo/odoo/blob/b22a23435a0cc42b7084ded21dbd4ef3a4a2113e/addons/stock/models/stock_quant.py#L562-L565
Therefore, in the `report.stock.quantity`, we are creating a hole
between `yesterday` and `in 7 days`. When performing the RPC
`read_group` to get the graph data, a key-context is defined
(`fill_temporal`). Thanks to this, the hole is filled by the server but
the generated data do not mean anything:
https://github.com/odoo/odoo/blob/80ec56bd246869567c3bbc746be1ebce52970a63/odoo/models.py#L2005-L2007
i.e., the value of `empty_item` is:
```py
{'id': False, 'date_count': 0, 'product_qty': False, 'product_id':
False}
```
Later on, on JS-side, when processing the `read_group` result:
https://github.com/odoo/odoo/blob/ee84815f2b57ed7ba096d3390aa8c6509e3f7845/addons/web/static/src/js/views/graph/graph_model.js#L235-L241
We are grouping by date and by product. As explained above, some data
have an undefined `product_id` so, in such case, `labels` will contain a
date and an `undefined` value. This explains why we have two lines on
the graph:
- one for the product P
- one for the data generated by the server to fill the hole in the dates
range
OPW-2800818
closesodoo/odoo#93248
X-original-commit: 0530fffe2343463500273b9b03470847276e64bc
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Since 362f6b6d5b, the control panel of an
action can be rendered only the first time the dom is mounted. Any
further remount won't rerenders do anything. The bom report needs to add
some buttons and a searchView. Previously, those widgets was mounted in
the set_html _after_ the first mount of the controlPanel. This report is
an extend of the stock traceability which also adds some buttons. In
this case the buttons are rendered correctly because they are added
_before_ the first controlPanel mount.
This commit makes the extra widgets to be rendered in the control panel
generated in a new specific method overridable in the bom report file
closesodoo/odoo#93245
X-original-commit: 39306370a3a7c5767a29bba216ffe61ab8c69544
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
On a traceability report, if a user clicks on a lot and prints the new
report, an erorr will be displayed
To reproduce the issue:
(Need mrp)
1. Create two storable and tracked-by-lot products P_compo, P_finished
2. Update quantity of P_compo:
- 1 x P_compo with lot L_compo
3. Create a bill of materials
- Product: P_finished
- Components
- 1 x P_compo
4. Produce 1 x P_finished (lot L_finished)
5. Inventory > Products > Lots/Serial Numbers, open L_finished
6. Click on Traceability, unfold the line and click on L_compo
7. Print the report
Error: an Odoo Server Error is displayed (RPC_ERROR)
Since [1], the route has changed
[1] e2f59a6dd1
OPW-2773967
closesodoo/odoo#91453
X-original-commit: c0aefc788059499a745fc1787a253b3367dce8d5
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Following odoo/odoo#87522,
the use of `fields_view_get` is deprecated.
All calls to it should be replaced by a call to `get_views`.
The fact it has not been in the above pull request is an oversight.
closesodoo/odoo#90750
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps to reproduce the issue:
1)Inventory > Configuration > Settings > Activate "Reception Report"
> Activate "Show reception report"
2)Choose a non english language
3)Sales > Choose SO > Delivery > Allocation
4)Click on the Assign/Unassign equivalent in the new language
Current behavior:
The word in the Assign/Unassign button is in english
Expected behavior:
The word in the Assign/Unassign button is in the new language
Explanation:
When clicked the button starts a function in js that changes the
button text context without translating the new text. We also modify
the text in javascript and the problem is solved.
Issue 2:
The button had fixed size specific to the english language, if a longer
translation in another language was used it was cut leading to make it
unuderstanble in some languages (e.g. german).
opw-2827247
closesodoo/odoo#90705
X-original-commit: 260f433f5600e568db59c82a9c2fc807c1204b5f
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Fockedey Martin (mafo) <mafo@odoo.com>
All named arguments on the catch block must be used. If for some motive
the named argument on the catch block is not used, its name must begin
with '_'.
closesodoo/odoo#85569
Related: odoo/enterprise#24867
Related: odoo/design-themes#552
Signed-off-by: Géry Debongnie <ged@odoo.com>
Reduces load_menus answer size by 32% (between 20kb and 200kb savings
for the initial loading of the backend, depending on the number of apps
installed). Support for SVG icons in the web client for menus/apps.
Reduced PNG icons for apps list (8 bits PNG instead of 24 as our icons
don't need more colors as they are flat designs)
closesodoo/odoo#84280
Related: odoo/enterprise#24200
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
Usecase:
- Install mrp with demo data
- Log in chicago company
- Go to manufacturing list view
-> Access error is raise due to multicompany rule
It happens because the state.res_ids contains all the mrp.production
even in SF company. So it try to read records in the wrong company
and raise the error.
Instead of doing a read, we change that and do a search_read like in the
classic process using the state.domain. So it filter the wrong records
before reading them
X-original-commit: 2077ee3b9312fc511d8fd5d328b5c4e329d9b784
Part-of: odoo/odoo#83430
Steps to reproduce:
- go to inventory report
- remove the "Product > Location" Group by filter.
Problem:
The buttons “Inventory at Date” and “Create” are like merged together because there is no margin right
opw-2721995
closesodoo/odoo#83453
X-original-commit: a33e04df672658c8306a1052b1db79f233f8c54c
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Fixes a couple of things;
1. Backorder use case when unassigning a move in reception report.
To reproduce:
- Create a Delivery w/ Demand = 8 of a stored product not in stock
- Create a Receipt w/ Demand = 10 of the product
- Assign 8 of product to delivery (don't forget to activate Reception
Report in settings
- Mark 4 of product as done > mark as done > create a backorder
- Open reception report in backorder (shows 6 instead of 4, this is a
known limitation of reception report) + unassign + close report
- Reopen report + assign 4
- Finish the backorder
Expected result: Delivery has 2 moves totaling a demand and reserved
amount of 8
Actual result: Delivery has 2 moves where 1 is fully reserved but the
other isn't and cannot be reserved (even though product in stock).
Issue was due to move split during unassign not taking into account that
the amount being unassigned could be greater than the amount still
assigned (due to backorder amount > demand qty since it doesn't know how
much was done in the original receipt). This would lead to the move
linked to the original receipt's move expecting a greater quantity from
the original move (and therefore not reserving any more quantities.)
2. Trying to unassign from an already done move. (i.e. backordered move
from above unassigned after the delivery is already done) isn't allowed,
so in case of unassigning from a done move, we don't do a split.
3. In case of failure of unassigning, fail gracefully (i.e. don't switch
button status since this is misleading).
Discovered during task: 2662730
closesodoo/odoo#83338
X-original-commit: 3c0c780032ed07da7ec14bdad8df2ff48fc5f4ef
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
2 issues:
- When going to the report forecast the value of the stock is computed.
However the stock user should not be able to access the valuations
- Since an access error is return the graph view is not instanciate and
the javascript code try to amend an empty result to the DOM. It results
with a traceback on top of 403 page
closesodoo/odoo#82074
X-original-commit: dbc6b1999ad478d0fdb5774624fd50ca4018be22
Related: odoo/enterprise#23185
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Improvements of the Inventory Adjustements page, among which:
- Add a new 'Apply All' button (without the need to select a record)
- Show the date at which the last count was done
- Add warning icon next to duplicated SN
- Allows to change the lot_id when empty and no quantities are set
closesodoo/odoo#78361
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Before this commit: when reserve/unreserve button were clicked, it was
opening action in new breadcrumb while it should not open new breadcrumb
instead it should display in self.
After this commit: reserve/unreserve button will open action and replace
current action and will not open new breadcrumb everytime we click.
task-2581265
Part-of: odoo/odoo#74695
If we have two companies A and B with B selected and we try to access the Forecast Report via a product, company A's warehouse is automatically selected, which of course creates a security error.
This fix modifies the ´get_warehouses´ method in order to return only the warehouses whose company is selected.
opw-2688135
closesodoo/odoo#80021
X-original-commit: 088e97aa3214578de99abbd47bd6aeccff244855
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Achraf <abz@odoo.com>
When reception report is viewed in a mobile screen, the "Print Label(s)"
buttons do not fit well, therefore we use a print icon instead of text
when in a mobile view. To ensure it looks good, we also update the
buttons to have equal width/height where applicable.
Part of Task: 2632884
X-original-commit: fadc2dddf12521b0f81096b6225d67951584b714
Part-of: odoo/odoo#79408
Previously the reception report > "print labels" would only print the
picking name (or SO if provided) + delivery address (if provided) when
not for a MO. Label has been updated to include the product name.
During this update a few other related improvements were made:
- make the label based on stock.move (so extending is no longer
needed in MRP)
- formatting of label is improved so now address will be truncated
instead of wrapping (and potentially losing lines at end of address)
- line padding is reduced so we can fit more lines in the label
- "Print Labels" button at source level will now be enabled when its
corresponding "Assign All" button is pushed (previously only the
"Print Label"s of each moves' line was enabled.
Part of Task: 2632884
X-original-commit: 9774c1ab1d68cf095b64a82b56f100d747fc8a56
Part-of: odoo/odoo#79408
This commit removes all the 'extend' initially introduced to avoid code
repetition and ensure visual consistency across Bootstrap and Owl dropdowns.
Despite achieving the desired results, using 'extend' in this context
was seriously impacting the bundle generation time, probably due to an
underestimated amount of Apps' legacy-code applied on these elements.
In order to achieve the same results, the chosen strategy is to add
Bootstrap default classes directly into Owl dropdowns.
Also, it moves code related to bootstrap dropdown in 'webclient.scss',
leaving 'core/dropdown/dropdown.scss' for Owl code only.
Due to the discrepancies between Bootstrap and Owl html
structure, the '.dropdown-item' class could not have been added
directly to Owl's '.o_dropdown_item' itself, without refactoring
the Dropdown component structure.
// ==== Bootstrap 4.6 default Structure ================================
<div class="dropdown-menu">
<button class="dropdown-item" type="button">Action</button>
<a class="dropdown-item" href="#">Another action</a>
</div>
// ==== OWL default Structure before this commit =======================
<ul class="o_dropdown_menu">
<li class="o_dropdown_item">
<span>Action</span>
</li>
<li class="o_dropdown_item">
<a href="#">Another action</a>
</li>
</ul>
// ==== OWL Structure after this commit ================================
<div class="o-dropdown--menu dropdown-menu">
<span class="dropdown-item">Action</span>
<a class="dropdown-item" href="#">Another action</a>
</div>
// ==== web.assets_backend.css Bundle Generation Comparison ============
With all modules installed (enterprise edition over runbot):
Before this commit, bundle took ~2.5s and ~4s to generate and weighted ~322kB (~2.5MB uncompressed)
After this commit, it takes between ~1.2s and ~1.6s and weights ~257kB (~1.6MB uncompressed)
closesodoo/odoo#77649
X-original-commit: 84715436d87bb05b421bc9ccaacda67d07571690
Related: odoo/enterprise#21370
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Co-authored-by: Stefano Rigano <sri@odoo.com>
Co-authored-by: François Georis <fge@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
- Avoid traceback when click on priority widget
- Also, fetch directly the lazy column if the web client read one record
(happen when we modify a single record).
closesodoo/odoo#77402
X-original-commit: eb26406cff7a0c61768c287a0525c2b6bc123f9e
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Since commit 0134495ba5 the reporting
views pivot, graph, cohort are written in full new framework.
Some applications still need the legacy ones, so this commit just implements
the lazy loading of those views.
In stock, report_stock_forecasted has been adapted in order to avoid having
a GraphView override: we now modify the canvas' height in pure JS.
*: board, stock
closesodoo/odoo#76931
Related: odoo/enterprise#21054
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
commit bc1a6faa51fef60bb64ea09f4e43f1120f9855bd add a rule to fix
tracability report but on a global level. However we won't this behavior
everywhere in odoo or at least if it's the case it shouldn't be specify
there
closesodoo/odoo#76713
X-original-commit: f96c78f701831ed7aa1798765e3e5f81d1a689c1
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Steps to reproduce:
- Install Manufacturing module
- Go to Manufacturing -> Operations -> Manufacturing Orders
- Create a new one and add at least 10 product components
- Move it to Done stage
- Click on stat button Traceability
- Unfold the components
- Print report
Issue:
Table header on 2nd page overlap table content.
Cause:
Wkhtmltopdf does not handle well table on multiple pages.
More info here: https://github.com/wkhtmltopdf/wkhtmltopdf/issues/2367
Solution:
Do not duplicate table header on next pages.
opw-2634492
closesodoo/odoo#76535
X-original-commit: 8cc791e2de0f708ff7d69574cc8a8a40ef61c02b
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
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>
The term was untranslated
Export missing stock terms
Forward-port of fb0383f8c1d4ef5817cf67
closesodoo/odoo#75155
X-original-commit: 4a0d1dfd2b48ecad107a687093ac34a3b0d67d60
Related: odoo/enterprise#20247
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Add reference of the traceability report's origin (production.lot,
manufacturing order, picking, ...) to the end of the
report.
Change the layout a bit so the data isn't squashed by
the border.
Task-2467686
closesodoo/odoo#74120
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
And convert the `t-esc` in the template to `t-out` while at it.
So this was a bit of a bummer initially, the PopoverWidgetField gets a
pile of JSON as its value (so from the server), and that pile contains
a template name (optionally) and... the template context,
basically. For leadDaysPopOver the issue was some of that context is
supposed to be rendered HTML to straight inject into the template,
marking that as HTML-safe would be a bit of an issue (having the JSON
specify which parts of the value it returns are HTML-safe being a bit
of a conflict of interest).
However turns out the thing is way over-complicated and
over-engineered: `lead_days_description` necessarily has a very
regular structure owing to being injected as a set of table rows, so
the various overrides to `_get_lead_days` just make their own lives
complicated by formatting the values they want to return into table
rows matching the format of an unrelated template.
Instead we can change the signature of `_get_lead_days` so the
"description" is a list of values to inject in the table (list of
pairs, each pair matching the corresponding columns of the table). The
template can then take care of formatting those values into table rows
the usual way, removing the need for any injection of raw content.
This also makes for better / clearer translation strings.
Infobox to help the user with the replenishment. Allow those actions:
- See the different supplier with their lead time, price and quantity
- Be able to select a supplier and set it on the orderpoint
⁻ See the last delivery by mmonth for the product
- Last purchase date for each supplier
Technicaly it use a wizard and a fields char with JSON used by
a widget to display a static template. Also it creates directly
the wizard in backend instead of just let the view manage the new
object since we need a button on a one2many and if the records do
not have an id, it's not possilbe to use it.
closesodoo/odoo#72039
Task: 2519761
Related: odoo/upgrade#2596
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
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>
Simon Genin (ges)