Load the fields_view of all views of the action together. If a searchview is
required, also load its fields_view and its filters.
Use lazy-loading for fields as they are required for the Pivot and Graph
views only, and may be used by Filters and GroupBy menus of the Search view
if the users clicks on 'Add a custom Filter/Group'.
The fields are thus also loaded directly if the first view of the action is
Pivot or Graph, and otherwise, they are lazy-loaded when/if the user opens
a Pivot or Graph view, or if he wants to add a custom Filter/Group.
Some refactoring of views API as well:
- Views must now be instantiated with their fields_view
- Move code requiring fields_view from start() to init(), or willStart() for
heavy processing.
- Remove view_type attribute from views as it was used to call
fields_view_get.
- Remove view_id parameter to views' init as it is no longer used.
- Move duplicate code from various views' init to the View widget.
- Remove view_loading() function from views as they now follow the classical
lifecycle of widgets (init -> willStart -> start -> destroy).
- Searchview now extends View like all other views.
- Remove useless function guard_active() as it was used for the form_view's
action buttons to wrap handlers to ensure that they are executed only if
the form_view is the current active view. This is not useful anymore as
from v9, views and their control panel are appended in the DOM
simultaneously, so one can't click on a button of a view which is not the
current active view.
A special case for X2ManyKanban views was handled in the Kanban view itself.
This commit makes the X2Many case identical to the general case by setting
options.action_buttons to true if the X2Many field is not readonly.
* This commit adds an easy access to products and variants from the app switcher / root menu, similar to what exists for contacts.
* Move an action to view stockable products to stock, as it is only executed from stock.
Before the patch:
- product A, with optional product B and C
- buy A with B and C as options
- buy (again) A with B and C as options
=> existing line A,B,C is incremented
- buy (again) A but with only B as option
=> existing line A,B,C is incremented
This was wrong as a new line should be created instead without option C.
Side note: this should probably removed as confusing to have duplicated lines
and has no interrest to keep the link.
* _cart_find_product_line
The method _cart_find_product_line is always called with only one record.
The fact that the return statement was inside the loop confirms the for loop is
not useful.
The method will now return recordsets instead of ids.
Convert the overrides to the new API for cleaner code and avoid old-new api
headhache.
Side note: the website_sale_option override logic is very counter intuitive and
should probably be refactored.
* _cart_update
Add ensure_one to be sure working on only one sale.order.
The method is always called on only one order and does not make sense to be used
on multiple (is the action that is done on one line of the cart).
The return format is the updated line without link to multiple orders.
Remove the for loop and assume self is only one order.
- remove field complete_name
is the same as the ORM field display_name, compute the name_get
- website_publish_button is duplicated
- write outdated, according to TODO (field color already renamed)
- Instead of open_website_url, should use website_publish_button
- styles, style_in_product, attrib_encode: are no longer used in templates
- remove unnecessary rebrowse
This check was added at d3678bf5 either
- to prevent browsing as public user (wrong as always browsed with SUPERUSER_ID)
- to refresh fields of the record (I find your lack of faith in the cache
invalidation distrubing)
- remove get_pricelist method
equivalent to call request.website.get_current_pricelist
The pricelist in the context is only useful when computing the price of the
product.
Do not modifiy request context but only a local copy.
active_id is only used for the computation of the extra price from variants
If the fixed quantity was higher than the produced quantity, the quantity of the
manufacturing order was used for the byproducts instead of the one specified on
the BoM.
This bug was due to the computation of the subfactor (`_get_subproduct_factor`
in mrp, because I love the modularity) that was computing remaining quantity,
only considering the variable quantities cases.
In fixed quantity, the MO quantity being lower than the byproduct quantity, it
was never fully produced.
Corrected the test to correctly check the quantities and handle the usecase with
an higher quantity in fixed byproduct.
Added a field subproduct_id on the stock.move object that allows to easily find
the attributes of the mrp.subproduct item without making hacky (and probably
wrong in case of more than one byproduct) search to find it back.
Closes#8031
Otherwise, when uninstalling the `purchase` module, this
menu is not deleted, while it should.
Besides, there is no reason to set `base.` to this xml_id:
It's not used by any other module.
opw-672130
* The refund sequence checkbox was not in technical features while the refund sequence selection was.This meant that in non-technical mode you could activate refund sequences but couldn't select one.
* This commit fixes the issue by setting the the checkbox to technical features as well, and setting the refund sequence selection to required once the checkbox is ticked.
* Some people were expecting a $ amount instead of the number of quotations due to the dollar sign on the stat-button. This should clear the confusion.
* New API migration
* Fix delay hours and total computation : Delay was wrongly computed as 0.0 in every case.
* Remove onchange from task. They were more confusing than helping.
* Since the last timesheets refactoring, timesheet entries are always linked to a project, and sale_service had the same dependencies as sale_timesheet.
* This commit simplifies the modules hierarchy by merging two modules that have a close functionality and that were both always installed after timesheets and sales.
On the product_template, the stat button to indicate the purchased quatity
is buggy in several ways.
1/ The states in the read_group domain have been mistaken with the states
on the picking (clap, clap)
2/ The read_group is seeking the fields product_id and quantity. Too bad, on
the model the name is unit_quantity (clap, clap)
3/ The displayed PO lines weren't chosen from a domain. So the computed quantity
didn't correspond to the displayed lines from the button (small clap, clap)
4/ The action_purchase_line_product_tree linked to the stat button is selecting
the PO lines where the product is the product id. Too bad, on the PO line
this is a product.product and on the current object this is a product.template
(epic clap, clap)
1/ Two menus having same id, so changed id of 'Mail Schedulers' menu.
So 'Events Types' menu is visible.
2/ UI improvements(changed menu string: Events Types -> Event Categories,
no more create and edit options for category selection).
Aaron Bohy