Introduction of 'data_manager' service which handles meta-data related to
actions and views (fields_views, fields and filters). Ideally, all RPCs to
get that kind of information should go through data_manager, as it holds an
internal cache.
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.
When a stock move was created in a picking with a product set with
a unique serial number existing in the stock of a specific owner.
If the owner was not specified for the stock move then a wrong message
was raised "The serial number 00005 is already in stock.". But the real
problem could come from function quants_get_preferred_domain which didn't
find the existing quant due to the fact that the system didn't check in the
right stock(owner). A new quant was then created with the existing serial number.
And a wrong message was raised.
opw:671783
When searching for a dropshipping route, we need to access the field
`picking_type_id`. If user is not allowed to read it because of the
access rule `stock_picking_type_rule`, he will get an access error.
opw-668926
* 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
In the backend product.product records are not just ordered on their
name, they are first ordered on default_code and then on name. The POS
should order records the same way.
opw-672284
In communtiy, the order of the accounts shown in the reports
didn't follow the order written in the legend(How account type affects your reports?)
Adviser > Chart of Account > create
opw:669270
When scanning items with a device like the Symbol MC3200 you are
presented with the Kanban view because of it's limited resolution.
In this view it is not possible to quickly set the quantity of scanned
products. Ideally users just want to scan the barcode, input the
quantity and repeat without having to click on virtual buttons on the
usually less than ideal touchscreen.
This implements a way for users to immediately start typing numbers
representing a quantity after scanning a barcode. The quantity will be
set on the specified m2x_field.quantity_field of the record associated
to the last scanned barcode. Because KanbanRecords are not editable
without opening a new view window.prompt is used. It will create an easy
to use native dialog of whatever device is being used. It also avoids us
having to implement a custom input field which would have to handle
keypress events like numbers, backspace, delete, etc.
We want to properly support devices like the Symbol MC3200. This is a
handheld computer running a modern operating system like Android or
Windows with an integrated barcode scanner. After installation of a
modern web browser and configuration of the integrated barcode scanner
Odoo works as well as it does anywhere else.
The main issue with these types of devices is that the displays (and
their resolution) are very small (3" @ 320x320 for Symbol
MC3200). Because of this a lot of tree views become awkward to use
because they require vertical scrolling. A Kanban view however scales
nicely on these displays.
This implements Kanban views for both the picking.form view and the
stock.inventory form view because those are the views typically used
when using a barcode scanner.
Doing this alone is not enough, because the barcodes module does not
work with Kanban views. Small changes where made to
barcodes.FormViewBarcodeHandler to make it work with both List views and
Kanban views.
An issue occurs in the following use case:
- Create an invoice, validate.
- Cancel it, reset to draft.
- Change the invoice date
- Validate the invoice
The date of the account move is still the first date entered. This is
because the accounting date has not been reset on the invoice, and
therefore it is not updated.
opw-671672
The `timesheet_ids` was added in the `sale.order` form.
As it was invisible, and not used by the attrs of another
field, or by an onchange, this is pointless to load
it for no reasons.
Besides, this could lead to issues regarding the form validation,
in case the analytic lines were not valid.
e.g. if an editable list view is used to load
these analytic lines and if a field in this editable list
has been made required,
while analytic lines exist with this field not filled.
In such a case, it was not possible for the user to correct the
analytic lines, as they were invisible, and it was not the place
to correct them anyway.
opw-672184
All the POS has to do is copy what accounting does. In the case of a
fixed tax we should do (from account.tax._compute_amount):
return math.copysign(self.amount, base_amount) * quantity
where copysign(x, y) returns x with the sign of y.
When base_amount is 0 it's positive, not negative. This also correctly
handles a base_amount of -0, although it's something that we shouldn't
encounter in the POS.
opw-672118
Before this we used line.price_subtotal directly when creating
account.move.line records, which causes issues when dealing with
non-integer quantities. In that case the amount paid by a POS customer
will never accurately be able to match the total computed amount of the
order.
opw-672118
Aaron Bohy