- Dec 03, 2014
-
-
Cédric Snauwaert authored
Recompute the name_template field if the template changes. backport of 41628fc7 + f25c5d85 to 7.0 plus some optimisations in triggers Fixes #3277
-
Martin Trigaux authored
When the list view is grouped, the page count should be hidden as irrelevant. However if it's fully hidden, the limit can no longer be changed. Instead of hidding the pager, this commit hides the arrows and replaces the content by the current limit to allow to be changed.
-
Benoit Guillot authored
Fixes #3973
-
- Dec 02, 2014
-
-
Julien Legros authored
-
Julien Legros authored
The average price computation is now deduplicated and moved to a separate function called in stock_move action_done. This makes sure it is always called when a stock.move is processed, even without going through the partial picking wizard. Fixes #2991 Closes #3949 OPW-615491
-
- Dec 01, 2014
-
-
Vincent Renaville authored
If a special period is present, it must be selected fist Fixes #3946
-
Eddy Ernesto del Valle Pino authored
Reminder emails are generated based on the list of attendees. The email_to field used to be a string with a list of emails separated by spaces while the comma is the valid separator (RFC2822). Fixes #3933 #3784 #2033
-
Géry Debongnie authored
See issue #3964 for more detail. Main problem was caused by commit f0e331e0. It set the key name+'__display' to false when reloading a record for all field types, but it was only concerned with many2many.
-
- Nov 28, 2014
-
-
Loïc Bellier authored
Invoice control field was invisible, and we cannot change value if none selected or copy picking in. Fixes #3636
-
Andrius Preimantas authored
When deleting a partner with some contacts, if the contacts had selected the "use parent address" checkbox, the address of the contacts was stucked in readonly mode (no checkbox to disable it). Disable use_parent_address for orphan partners. Fixes #3611 #3613
-
- Nov 27, 2014
-
-
Olivier Dony authored
Remove the intermediate rounding inside _compute_qty(), as it is not necessary after rev. fa2f7b86 and has undesired side-effects. An extra float_round() operation inside _compute_qty() had been added at rev. 311c77bb to avoid a float representation error in UoM factors that could bias the ceiling() operation done as the last conversion step. Example 1: Dozen has a factor of 1/12, which was previously stored in the database with a decimal accuracy of 12 significant decimal digits. This meant the factor was exactly stored as 0.08333333333333. When reading this back into a Python float, the precision was not sufficient, and the UoM conversion of 1 Dozen to Units gave a result of 12.00000000000047961... After the final ceiling() operation to Unit's rounding, the converted value ended up as 13. This problem was initially solved using an extra rounding. However at revision fa2f7b86 the decimal precision used to store UoM factors was increased to preserve all significant digits. This added the extra precision necessary to read the Dozen factor back into an accurate float value of 1/12, and the conversion of 1 Dozen now gives 12.0 Units, even without the intermediate rounding operation. (Works for other factor values too) At the same time that extra rounding operation has undesired side-effects, as it requires a fixed precision derived from the rounding precisions of the UoMs. But there is no given precision that would work in all cases for this intermediate value. It is always possible to find a valid combination of UoM roundings that breaks that intermediate step, e.g. by forcing integer roundings. Example 2: Let Grams have a rounding precision set to 1 because no smaller quantities are allowed, and Kilograms a rounding of 0.001 to allow representing 1 Gram. (gram factor = 1000 and kilogram rounding = .001 by default) If we try to convert 1234 Grams into Kilograms, the extra rounding introduced in 311c77bb will cause a rounding of 1234.0/1000.0 at the precision of Grams (1), which gives 1.0 as a result. The net result of this conversion gives 1234.0 Gram = 1.0 Kilogram, while the correct result (1.234 Kilogram) is perfectly compatible with the UoM settings. Similar errors could be triggered with various rounding settings, as long as the intermediate rounding needs a finite precision. Two extra tests have been added to cover Example 1 and Example 2. -- Related to #2072, #1125, #1126, #2672 Closes #2495, #2498
-
Denis Ledoux authored
-
Sandy Carter authored
The name_get of res.partner.bank uses the format_layout to generate the name of the bank. As every field is not required, we may get 'False' in the name. Replace these missing values by an empty string. Fixes #3590
-
Mohammad Alhashash authored
prodlot_id field may be required due to constraint `_check_tracking`. When a stock.production.lot is deleted, the constraint on linked stock.move is not checked. To avoid inconsistency, restrict the suppression. To allow the modification of existing stock.move, remove the states attribute on the field definition. As removal of serial may impact the traceability, it makes sense on buisness point of view to force the modification of previous stock.move, even if the constraint would not have been violated. The list of linked stock.move is present on the serial form view making the operation easier. Fixes #3560, lp:1176912
-
- Nov 26, 2014
-
-
Pierre Verkest authored
Fixes the issue #1216 (follow the link for more information). The issue was caused by a hack in list view: the magical suffix __display is used in render_cell to determine if a many2many field should be updated. This commit simply makes sure that old many2many fields + __display keys are cleared. A better way would be to redesign/refactor the list view to avoid that hack in the first place. But this would be a much more complex task.
-
Denis Ledoux authored
if the bom is phantom and has no line, we attempt to find a new bom with the default product uom This is possible that we find the same bom that the current one In such a case, we must not explode, to avoid recursion.
-
Danimar Ribeiro authored
Fixes #3879
-
Denis Ledoux authored
-
- Nov 25, 2014
-
-
Denis Ledoux authored
If a company contact (a partner with a company set as parent) had invoices, and the company of this contact was duplicated, all the invoices lines were duplicated, on the original invoice moreover (new lines were added on existing invoices)
-
Denis Ledoux authored
When the user was in timezone UTC + 1, and added a project.task.work which created an analytic entry line (timsheet activity), if the datetime was set to 11/25 00:00:00, the date on the analytic line was set to 11/24, because this was the truncated stored value(UTC Time), which was 11/24 23:00:00
-
- Nov 24, 2014
-
-
Martin Trigaux authored
Set a default value for factor when creating a new uom. Could not create a new UoM with type reference (if creates a reference uom, no need to pass a factor). Change the readonly filter to (type = bigger) to make the field writable for reference uom. This is needed to force the reset of the factor when switching of type (onchange_type). As the field was readonly, kept the old value for factor.
-
- Nov 19, 2014
-
-
Denis Ledoux authored
This rev. 73072272 ensured to not (re-)set the state 'confirmed' to exploded moves with a more advanced state (for instance, 'assigned') Nevertheless, the location chaining is performed on the move confirmation, through the action_confirm method of the stock.move model. Besides, the resulting moves of the _action_explode method had the state 'confirmed' on creation, the 'confirmed' state wasn't set by the method 'action_confirm', meaning that the moves were confirmed without having the location chaining done. Allowing moves to go through the action_confirm method even if the state was 'confirmed' or further triggered the location chaining. Preventing already confirmed moves to go through the action_confirm method prevented the location chaining, thus. We now create the resulting moves with the 'draft' state, and then confirm them through the procurement workflow signal 'button_confirm'. Thus, the resulting moves are confirmed by going through the action_confirm method, writing the confirmed state and triggering the location chaining at the same time. We then write the 'assigned' state if necessary. opw-617235
-
- Nov 18, 2014
-
-
Frédéric van der Essen authored
-
Denis Ledoux authored
-
- Nov 14, 2014
-
-
Denis Ledoux authored
But should use date or datetime according to the widget type This fix is related to 69d60465
-
Martin Trigaux authored
The delivery of a purchase order was not keeping the currency and cost price from the purchase order for the reception. This was problematic for orders where the invoice was generated from the picking (Invoicing Control: Based on incoming shipments). The currency of the purchase order was kept while the cost was the one in the company's currency. It's better to keep the currency of the purchase order to make the invoice as it's usually the one expected (and not convert everything to the currency of the company). opw 615555
-
Denis Ledoux authored
This rev. 06104ba5 Added the dirty flag on the o2m field when the editor of the editable list was enabled (meaning that the editable list has been altered)) because the dirty flag was not set correctly by the one2many during the edition, at the time. It looks like this is now the case Besides, as now, we valid all the editable list of the form, wether or not the editable list was altered, we must not set the o2m as dirty anymore.
-
Denis Ledoux authored
-
Denis Ledoux authored
First, name_search searches on default_code, then, if the limit is not reached, it searches on the product name The results found from the default code search must be removed from the search domain when doing the search on the product name, to avoid having results already found by the search on the default_code opw-618015
-
Martin Trigaux authored
When a picking is confirmed, the generated account.move(.line) should take the company, accounts, journals and period with the same company as the picking, not the one of the current user. This was problematic if a user in a company confirm a picking linked to a purchase order done in another company. For real time valuations, the generated accounting entries were mixing both companies. Fixes #3466
-
Martin Trigaux authored
-
- Nov 13, 2014
-
-
Cecile Tonglet authored
-
Rifakat Haradwala authored
search bar does not suggest date field format based on user's locale and always shows based on mmddyy using Date.parse, opw:615276 Note: starting in 9.0, datejs has been replaced by momentjs, so this problem should be solved in a better way.
-
- Nov 12, 2014
-
-
Frédéric van der Essen authored
[FIX] point_of_sale: fixed rounding issue for pos order when discount ad...
-
- Nov 10, 2014
-
-
Martin Trigaux authored
date field on a project.task.work is not required while it is on the hr.analytic.timesheet (with default value). Avoid error if fill a task work without date, fallback on context_today.
-
Martin Trigaux authored
The field bom_id is required on a manufacturing order and deleting a mrp.bom would block the current mo. Restrict the suppression for manufacturing order in progress. Fixes #3417
-
Dhruti Shastri authored
Timesheet activities (hr.analytic.timesheet) are generated when a work activity (project.task.work) is logged on a task. These are updated if the project of the task is modified. This patch applies the same behaviour for tasks without project, the timesheet activities are generated once a project is set on the task. To avoid redundency in the code, extract the computation in a distinct method. Fixes #701, opw 609481
-
- Nov 06, 2014
-
-
Ravi Gohil authored
-
Denis Ledoux authored
once widget extended with ReinitializeFieldMixin, the event binding with the binary file input and the on_file_change method can be done in initialize_content instead of start This fix is related to d36c8b5c
-
Denis Ledoux authored
The add attachment button should be displayed while being in edit mode, but not in view mode As the widget depends on the form actual mode, the widget should be re-rendered each time the actual mode changes This is the point of the ReinitializeFieldMixin class
-