The function "product_uom_change" was built to reset the price unit
of a SO line when the uom was changed. Before this fix 503820a, the
price unit of the SO line only depended on the price list then it was
not needed to pass the fiscal position to this function.
After this fix 503820a, the price unit of a SO line also depends on
the taxes set on the SO line(e.g.:if an included tax is deleted, the
price unit must be recomputed without this tax). Then to recompute the
unit price, the function "product_id_change" must take into account
the fiscal position set on the SO to consider the right taxes to
recompute the unit price.
The fiscal position set on a SO must be passed to onchange_product_uom
each time it will be called because the price unit will be recomputed.
f26b94f had as goal to filter the taxes of the product
according to the company when the sale.order
was created/edited as SUPERUSER_ID
(Who ignores the record rules).
Unfortunetaly, to filter the taxes,
it used the company of the customer,
while it's actually the company of the order which
should be used.
Indeed, for instance,
partners can be shared among all companies.
It was way less simple to access the company
of the sale.order, this parameter being
not available in the on_change method signature.
This is the easiest way to solve this issue
without breaking the API / retro-compatibility.
opw-647819
The field "state" in "sale.report" model must consider the state used
by "sale.order.line" to be consistent with the view created in this model.
The function _sale_count in 'product.product' model must return
the number of product included in a "confirmed" or "done" sale order line.
opw:644200
This rev. is comparable to 0b18a5afec
The action action_order_line_product_tree is used in both
product templates and product variants forms.
Therefore, the default_product_id: active_id in the context
cannot be used,
As sometimes the active_id will be a product template,
sometimes it will be a product variant.
I believe two different window actions should be used,
instead of sharing a common one and making hacks.
Nevertheless, as we avoid taking risks in stable releases
This should probably be performed in master.
Rebranding has been done in:
- data/demo files
- html templates
- help notices
- comments
- logger messages
- and other various messages
(Commit taken from odoo-dev:8.0-improve-openerp-odoo-rlu at rev 7deaa08)
Closes#1260
Add group of countries res.country.group
Add get_fiscal_position method a method to compute a fiscal position based on company_id, partner_id, delivery_id
The meaning of res.partner.fiscal_position is now a forced a fiscal position.
The default implementation should handle simple cases, like VAT in UE and sales
tax in the US, but the method can be overriden to handle more complex ficals
rules.
[MERGP] Inline Searchview
This task split the searchview in two parts: SearchView and SearchViewDrawer. The drawer is displayed inside the main view and the searchview stays in place. It also changes the scrolling behavior of the web client: the main view area can scroll without affecting the UI (so the various menus stays in place)
Because of this, other large changes have been made:
the drawer has been redesigned,
the Custom Filter widget has been split in two (Custom Report and SaveCurrentFilter),
the main view is now scrollable, so the UI stays in place and only the view can change
The text 'Group By...' has been changed into 'Group By' (most addons had to be modified)
bootstrap classes are used when it makes sense (for example, badge)
the left menu is also scrollable (separately from the main view)
It is likely that some stupid bugs have been introduced. Please don't hurt me.
Goffin Simon
Christophe Simonis
Denis Ledoux
Josse Colpaert
Julien Legros
qdc
rlu-odoo
Thibault Delavallée
Antony Lesuisse
ged-odoo
Fabien Meghazi
Prashant Panchal (OpenERP)
Quentin (OpenERP)
Ravi Gadhia
chm@openerp.com
Gery Debongnie
Josse Colpaert
Christophe Simonis
Denis Ledoux
Randhir Mayatra rma-openerp
Ravish (Open ERP)
DJ Patel