this is due to commit 6ed774de61 and a37bad205b which removes the active_id from context if the target==curent which is the case of this widget, we therefore can not use active_id here.
fix#2385
Indeed using fromkeys with a list / dict as argument leads to the creation
of shared list / dict. This could create some ugly side effects when
used in loops. This commit fixes or cleans this kind of statement to avoid
unwanted side effects.
A squashed merge is required as the conversion of the apiculture branch from
bzr to git was not correctly done. The git history contains irrelevant blobs
and commits. This branch brings a lot of changes and fixes, too many to list
exhaustively.
- New orm api, objects are now used instead of ids
- Environements to encapsulates cr uid context while maintaining backward compatibility
- Field compute attribute is a new object oriented way to define function fields
- Shared browse record cache
- New onchange protocol
- Optional copy flag on fields
- Documentation update
- Dead code cleanup
- Lots of fixes
When a purchase requisition is created from a procurement order, a first stock move is created, not associated to any purchase orders
Then, on purchase order creation and confirmation, in the purchase requisition, new stock moves are created, associated to the purchase order.
The existing stock move issued from the procurement order which created the purchase requisition remained untouched, leading to wrong inventory values
To fix this, the destination location of the stock move of the procurement order is written on the source location
A proper fix should be to use a dedicated workflow for puchase requisition, but this can't be done in 7.0, it has to be done in master/trunk
If a purchase requisition is created instead of a purchase order for a procurement order, the method make_po should not return the id of this requisition, as methods calling the make_po method expects ids of purchase orders, not purchase requisition ids.
Besides, on purchase requisition done or cancel, we set the procurement order accordingly, without the use of the workflow. We consider this as crappy, the proper fix should be the use of a dedicated workflow for purchase requisition, but I cannot be done in stable branches. This aims trunk/master.
[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.
Will Stott
Olivier Dony
Cedric Snauwaert
Josse Colpaert
Thibault Delavallée
Fabien Pinckaers
qdp-odoo
Raphael Collet
Antony Lesuisse
Jaydeep Barot
Christophe Simonis
Denis Ledoux
ged-odoo
Fabien Meghazi
Christophe Matthieu
Launchpad Translations on behalf of openerp
Quentin (OpenERP)
Bharat Devnani (Open ERP)
Richard Mathot (OpenERP)
Rakesh Sindhav (OpenERP)