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
fixes#595
In the case where a property for the company exists but has no related record (e.g. in case of type m2o with no defined value), not setting a value to this field for a new record would create a new property (as browse_null is not an instance of browse_record)
When attempting to parse client date, value is not always a string.
We force the toString when adding the leading 0, as the replace method is for string
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.
The Partner VAT Intra XML delaration needs to have the VAT number
in the format without the country code prefix.
The current behaviour was to include the country code prefix in the
report which causes an SQLException error on uploading the XML file
to the Federal goverment's website. While the error is non-descriptive
fixing the VAT number format fixes the error.
[FIX] view_list: Add context propagation for m2m list view
If the _rec_name field of a model is translatable, the value was not translated when displayed in a list view through a many2many field (e.g. server_action_ids on base.action.rule).
When searching for a record in a m2o field, if we click on 'search more' we loose the focus on the field and select the first suggestion (which triggers potential on_change). This prevents the selection for this case.
When a module is uninstalled, this will also uninstall modules depending of it. To avoid unexpected loss of data, this patch list the modules that will get impacted during the installation.
This also affects the configuration pages with on change warnings.
When adding an item to the editable list, the focused field was no longer the first visible field
This is related to revision 4a508885ac
visible_columns list is not ordered
the code handling the keydown events was moved, but the variable this
was not adjusted accordingly, resulting in a broken navigation.
It is now possible to press LEFT and RIGHT again to move the focus
between facets.
In editable list, on keypress enter, the _next method is called, saving the current line and starting the edition of the next one
The _next is triggered before the date(time) field change event, and, therefore, the saved value of the date(time) field is the old one
Prior to this fix, the domain was set in the onchange methods onchange_company_id. Therefore, if the onchange was not triggered, the domain wasnt apply (e.g. while editing an existing invoice).
[FIX] event: change the field nbevent to make sense
The field nbevent was representing the number of registration with value of 1 for events without registrations (which makes no business sense). Fix to actually represent the number of registrations and display a better field name.
_read_flat: remove duplicated fields in read call
get many2one: as False is instance of int, check the value of x first to avoid calling a name_get with a list of False
When we were reading twice a m2o field where at least one result is null, the first call to name_get would set the value to False instead of None and then accepted by the filter 'isinstance(x, (int,long))'
sale_order module override state field of sale.oder (sale.sale.py) and forgot to reset the track_visibility, therefore sale orders state changes are no longer tracked once this module installed.
This will make sure already processed rules are persisted
in case a timeout occurs while processing the next ones,
ensuring that *some* progress can be made in most cases.
A safety guard already in place prevents the recursive
trigger of rules while another rule is being executed,
as a simple measure to prevent endless loops.
This guard was missing when processing time-based rules.
A programming error introduced at rco@openerp.com-20121220142445-emzzvhlw400q37c9
fails to properly check when a rule has already been executed in the past.
Time-based rules should only be executed if the trigger date is in the past and:
- either they never executed before
- or the last execution date is older than the trigger date
Executing a rule always updates the `last_run` value, which would
always force a useless registry reload to occur. Only signal the
change if the rule applies to a model that was not previoulsy
monitored for base action rules.
Denis Ledoux
Alexandre Fayolle
Thibault Delavallée
Yogesh Parekh
Christophe Simonis
Mohammed Shekha
Martin Trigaux
Jos De Graeve
Martin Trigaux
kevin wang
Jacques-Etienne Baudoux
Ruchir Shukla
Richard Mathot
Yann Papouin
Najlaâ El Khayat
Yannick Vaucher
xmo-odoo
Géry Debongnie
dhr-odoo
Olivier Dony
Ravi Gohil