- Nov 04, 2014
-
-
Denis Ledoux authored
This is related to rev. a218a9ed The condition is good, but not in the right place: It should be done once all read_slice (all columns records) are fetched, not at each read_slice end
-
Manuel Vázquez Acosta authored
-
Martin Trigaux authored
When an action opens records in list (or other) mode in a popup (target:new), the pager should be kept. It can be removed in form view. Fixes #742
-
Denis Ledoux authored
Some prices, as standard_price, being a property, are company dependent. Therefore, when browsing as superuser, force_company is mandatory to get the property of the user company
-
Stéphane Bidoul authored
[FIX] account: Preserve analytic account on tax lines which are on same general account as invoice line After careful analysis, I'm now convinced it is a good thing to preserve the analytic account on taxes line which have the same general account as the invoice line. This is the best default case and will save time for users, while leaving the flexibility to adapt the analytic account on taxes manually.
-
Stéphane Bidoul authored
[FIX] account: Error when manually adding analytic account in the generated tax lines on an invoice fixes #374 fixes https://bugs.launchpad.net/ocb-addons/+bug/1084822 The fix considers invoice tax lines with different analytic account are equivalent for the purpose of checking if the list of tax line is complete. Caveat, this changes the structure of keys in the dictionary returned by account.invoice.tax's compute method, I suppose this is ok for the master branch.
-
- Nov 03, 2014
-
-
Thibault Delavallée authored
Restauring changes removed by the update of the library bff34f40 17a23c60 cc23ddd0 5c45aac7
-
Paramjit Singh Sahota authored
Update the cleditor lib from v1.3.0 to v1.4.4 fixing IE11 issue, opw 614826
-
Martin Trigaux authored
Partial backport of 5f061291. Fixes #2837
-
- Oct 31, 2014
-
-
Denis Ledoux authored
opw-617036: In my current timesheet, if you add a a required field on the timesheet ids lines, and add data in the summary tab, it was possible to validate the timesheet lines while requried fields were missing.
-
Mohammad Alhashash authored
Allow setting origin/backorder when copying new stock.picking Fixes #379, lp:1098557
-
Martin Trigaux authored
When a line is not present in the partial delivery wizard, computation variables are initialized with generic values (zero quantity, zero price,...). Instead of setting the uom to False, keep the quantity of the move. This makes a difference only when the quantity of the move is 0. That means that the move will be marked as complete and can be processed. This avoids trying to update the stock.move with a uom at False. opw 616844
-
- Oct 30, 2014
-
-
Julien Legros authored
This is a workaround for an ORM limitation. A stored function field is not updated when it should if the "source" field is also a stored function field
-
Sandy Carter authored
In certain cases, before running an update unregistered models will try to register hooks. Trying to wrap create and write on these will cause AttributeError on model_obj which would be None Signed-off-by:
Sandy Carter <sandy.carter@savoirfairelinux.com>
-
- Oct 29, 2014
-
-
Christophe Simonis authored
-
Mohammad Alhashash authored
Implements the UoS TODO items on stock.picking.do_partial() to fix #1432. Add a new method _compute_uos_qty() on product.product to computes product's invoicing quantity in UoS from quantity in UoM. The created invoice will use the product_uos of the stock.move, meaning keeping the quantity specified on the partial picking and the unit of measure of the original stock.move (e.g. recieving 1 dozen from a 12 unit picking should either get uos=dozen, uos_qty=1 or uos=unit, uos_qty=12, not a mix of both) Fixes #1432, opw 611479
-
- Oct 28, 2014
-
-
Denis Ledoux authored
This fix is related to rev. b1df5aab
-
Julien Legros authored
-
Denis Ledoux authored
This reverts commit 07906822. This fix is not yet ready. See PR #3295
-
Denis Ledoux authored
General totals were not computed at all, due to the condition "if not self.ids" which was always true as self.ids wasn't set. Besides, a parameter allows to display only partner with balance greater than 0, which was completely ignored by the totals computation methods: The totals always included all partners, even those having balance equals to 0
-
Antonio Esposito authored
When generating the report 'Timesheet Profit', got a warning "The domain term '('user_id', '=', [...])' should use the 'in' or 'not in' operator." This warning is due to the use of the '=' operator to compare the field 'user_id' while the reports sends a list of ids. Fallback to still accept a single id in case of customised reports.
-
- Oct 27, 2014
-
-
Martin Trigaux authored
When computing the cost price to display, take the uom into account. The cost of 1 Unit or 1 dozen should not be the same. opw 599727
-
Ravi Gohil authored
Source and destination locations are required and not displayed in the form view. Adding new items when recieving a picking can not be easily guessed as we can put different locations for each line, using default locations may not be the expected result. Instead should modify the original picking or create new one. Fixes #2074, opw 612768
-
Martin Trigaux authored
At the end of the onchange call product_id_change, the uom may have changed (e.g. if product in different category). To compute the quantity, we need to use the new uom and not the first one (that may be Unit, default value)
-
Denis Ledoux authored
+ use ir.model.data get_object_reference method for better performance (cached result) opw-616616
-
Denis Ledoux authored
Instead of html cleaned html, to allow display blockquotes opw-614729
-
Martin Trigaux authored
-
- Oct 24, 2014
-
-
Martin Trigaux authored
The computation of the price without pricelist should take care of the unit of measure. e.g. if computing discount for objects in dozen (on a product with price in unit), returned unit price should be (price*12) where 12 is the factor to go from dozen to unit. Otherwise the compared prices (with and without pricelist) would not use the same unit of measure and the comparaison would be inconsistent. (opw 599727)
-
Martin Trigaux authored
The price_surcharge attribute must be computed based on the reference unit of measure (divided by the factor). This is to make sure than 12 units and 1 dozen have the same price after pricelist computation (opw 599727). Added test checking the correctness of pricelist computation based on unit of measures.
-
Cecile Tonglet authored
Fixes #3237 cherry-pick of 8e720494
-
Christophe Simonis authored
[FIX] When using "--stop-after-init", set the return code correctly. A non zero return code reflect the number of databases that fail to load/update Backport of 2c4e370b and 33ce0e73
-
- Oct 23, 2014
-
-
Julien Legros authored
-
- Oct 22, 2014
-
-
Denis Ledoux authored
-
Martin Trigaux authored
Add readonly attribute to avoid sending both factor and factor_inv value to the backend when saving. This was possible if the user switched between uom_type to fill the two fields.
-
Cédric Snauwaert authored
Remove the hardcoded precision of 12 on factor and factor_inv, to use the complete natural precision of NUMERIC types, preserving all significant digits. e.g. a UoM with a factor_inv of 6.0 used to be computed as: factor_inv: 6.0 -> factor: 0.166666666667 (1.0/6.0, rounded to 12 digits) -> factor_inv: 5.999999999988 (1.0/factor) which could lead to errors such 12*0.166666666667 = 2.000000000004 instead of 2.0 Slightly changed the way the ORM handles float fields to allow setting `digits=0` as a way to explicitly require a NUMERIC value but without enforcing/rounding the values at the ORM level, i.e. a truly full-precision field. NUMERIC type has unlimited precision but is less efficient so should not be used as the default behaviour, which is why we keep float8 as an alternative. Modified the view to display the product UOM factor with a 5 digits value by default. This value is for usability purpose only, the field still accepts bigger precision, by setting the `digits` option on the field in the form view. This change is safe in a stable series, the `digits=0` alternative is treated the same as the default `digits=None` everywhere in the framework, except when creating the database field.
-
Martin Trigaux authored
Add rounding_method parameter on float_round method to offer HALF-UP (default, usual round) or UP (ceiling) rounding method. Use the second method instead of math.ceil() for product reservations. For UP, the python math.ceil() method uses "torwards infinity" rounding method while we want "away from zero". Therefore we use the absolute value of normalized_value to make sure than -1.8 is rounded to -2.0 and not -1. Fixes #1125 #2793 This is a cherry-pick of d4972ffd which was reverted at 333852e1 due to remaining issue with negative values.
-
- Oct 21, 2014
-
-
Martin Trigaux authored
Save the NumberedCanvas state before doing a page reset. The order of execution when rendering an rml report is the following: 1. init canevas (_pageNumber = 1) 2. render the page element 3. if still pages to render, afterPage method 4. if still pages to render, showPage method (_pageNumber += 1) 5. back to step 2 for each page 6. draw the ResetPage element (setting flag _doPageReset=True) 7. end the document build with afterPage & showPage method The PageReset element should be executed at the end of the rendering of a story (subdocument) to reinitialize the page numbers to 0 (for new story) and insert the pageCount element for that story with the total number of pages (needed if want to use tag <pageCount/> in rml). In case of NumberedCanvas (e.g. used in Trial Balance report), the numbering is generated at the end of the build using the _saved_page_states dict in the canevas. To have an accurate _saved_page_states content, it needs to be saved before the pageReset. Fixes #2225
-
Denis Ledoux authored
In the report pos order, average_price was set as a numeric(16,2), therefore, if the amount was too big, it led to a psql crash: A field with precision 16, scale 2 must round to an absolute value less than 10^14.
-
- Oct 20, 2014
-
-
Julien Legros authored
In some cases (e.g. with record rules), the name_get might not have access to the parent name. Therefore a parent_name related field solves the issue (as it read with as superuser).
-
Martin Trigaux authored
-