Add invoicing related fields on anlytic account tree view for the invoicing group only
Otherwise, when a user not having the invoicing access rights displays the analytic account list, he gets an access right error.
opw-619485
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.
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#2991Closes#3949
OPW-615491
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
See issue #3964 for more detail. Main problem was caused by commit
f0e331e005. It set the key name+'__display' to false when reloading
a record for all field types, but it was only concerned with many2many.
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, #2672Closes#2495, #2498
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
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.
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.
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)
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
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.
This rev. 7307227 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
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
This rev. 06104ba553
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.
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
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
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.
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.
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
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
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 d36c8b5c9b
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
The report includes all due payments, not only the one after the maturity date.
The maturity date is displayed in the report so no confusion is possible for payments below the maturity date.
Fixes#3064
To valid all editable list line, we iterate on the lines and set the editor form with the line value, using set_value.
The _inhibit_on_change_flag should be set to True to avoid triggering on changes events
opw-617395
When validating a SO containing a `make to stock` + `manufacture` product
(with bom + orderpoint), we have the following stock moves:
* Product move
* Manufacturing order
Selling 1 such product would yield 2 as incoming quantity, an
inconsistency that this commit solves by setting the location_id of the
product move to the MO's location_dest_id (in the same fashion that
the create_pickings method does in an mts/buy case)
opw-616229
This is related to rev. a218a9ed3f
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
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
[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.
[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.
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.
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
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
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>
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
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
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.
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
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)
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)
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.
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.
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.
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 d4972ff which was reverted at 333852e due
to remaining issue with negative values.
Backport of 79bed94 (project user access to resource.calendar) and adding the access to resource.calendar.attendance.
It is needed to compute function fields such as day_open (present in form view of project.issue)
Fixes#3201
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.
And fallback of any type if there is none of type email
This fix allow the communication between two mail thread from two different Odoo servers having message creation subtypes, like project issue or crm lead
In edit mode, in a *2many with many2many_tags, when adding a new tag when none was set, discarding the form let the new tags displayed while it shouldn't (only a display issue, the tag wasn't added in database)
Fixes#2926
If an email contains several text/html parts inside a multipart email, the previous code was only keeping the last content part.
The Content-Type: multipart/mixed allows several independent part (RFC1341 7.2.2), so two html is technically valid.
With this patch, the two parts are concatenated. (opw 614755)
Modify append_content_to_html regex to make sure the regex keeps the content of the html instead of removing it.
e.g.: "123 <html> 456 </html> 789" used to be stripped to "123 789" while we expect "123 456 789"
Use group_production_lot for serial options, group_stock_packaging for packaging, use group_tracking_lot for pallet/parcel
Groups are removed completly from the view for stock.tracking as they render the view useless.
Always display weights on the product form
They really have nothing to do with the logistic units and we don't have another group to restrict them to.
Fixes#1443
When computing the price difference amount do not integrate the eventual discount and taxes included in the price.
Otherwise the total of the generated accounting enty would be higher than the total of the invoice. opw 611350
When no result is found on the function field 'invoice' (account.move.line), instead of returning {move_id: (False, '')}, return {move_id: False} (expected for m2o fields)
Fixes#2138, opw 613096
- The res_config.xml file was missing in the manifest (so couldn't check the use of FB and Google OAuth from the general settings)
- The default value for these oauth configuration were not set
The name_get of a product will use some information (e.g. default_code) based on the supplier.
The matching of the supplier should use the commercial_partner_id in case the supplier info are on the company and the partner_id in the context belongs to the company (e.g. creates quotation with a contact of the company).
Fixes#1219
If the salary compuation gives a salary of zero, skip the creation of the account.move.line (not good to have lines at 0).
Fixes lp:1298116, opw 605816
This reverts commit d4972ffdb6.
Seems to break some cases, at least in _product_reserve from stock/stock.py
Actual use case:
SELECT product_uom, sum(product_qty) AS product_qty FROM stock_move WHERE location_dest_id=%s AND location_id<>%s AND product_id=3645 AND state='done' GROUP BY product_uom;
returning 1 | 6
SELECT product_uom,-sum(product_qty) AS product_qty FROM stock_move WHERE location_id=%s AND location_dest_id<>%s AND product_id=%s AND state in ('done', 'assigned') GROUP BY product_uom;
returning 1 | -6
results += cr.dictfetchall()
total = 0.0
results2 = 0.0
for r in results:
amount = uom_obj._compute_qty(cr, uid, r['product_uom'], r['product_qty'], context.get('uom', False))
results2 += amount
total += amount
Total = 1, amount = -5
It should actually be
Total = 0, amount = -6
The group_by query expects the context to have group_by_no_leaf = true,
so we can not just blindly forward the context to the groupby query.
This is a defensive way to fix the problem, to avoid other possible
crashes. But the context shouldn't have group_by_no_leaf anyway,
it does not make sense to explicitely do that in the action
Fixes problem when we try to sell 12 units of a product and change it to 1 dozen,
the algorithm was then trying to recompute the original amount and was getting
12,0000048 as a result which was then passed to the ceiling method, getting 13.0!
See also previous commit and issue #1125, PR #1126
Modified product ceiling() to use float_round() with special mode
for rounding UP (away from zero), avoiding pathological cases where
float representations errors were ceiling to the superior unit.
Also added correspding tests for rounding_method=UP
Fixes issue #1125, and replaces PR #1126.
Even if this should never be used in normal portal environment, if a user with enough access rights tries to create an invoice, this would crash. We don't need context here (opw 612591).
When setlast_tracking is called on a large number of moves in a picking
(e.g. when splitting moves in a picking), the time to complete grows
exponentially. The reason is that it loops over all the moves of
a picking, even if it keeps only the last tracking.
The method now uses a search() with a limit so it doesn't need to browse
all the moves.
Added test to check the behaviour of setlast_tracking
Fixes#2448
When opening a lead/opportunity from the phonecalls view, we did not open the correct view (always the lead).
This will use the type of the crm.lead to determine which view should be used, opw 608493.
The stock_partial_move wizard removes the required attribute for the field picking_id on a stock.partial.move. This means that we could get moves without picking_id and the previous line was failing ('NoneType' object has no attribute 'currency_id'). opw 614531
The cleditor width does not include the margins. Setting 100% will make the editable area too large (104%) on Firefox (opw 611700).
This issue was already fixed in newer releases, from commit 9247c37de7
Nevertheless, it introduced a new issue: while editing the form, the content of widgets html which were located in hidden notebook pages weren't displayed when displaying the page content.
opw-614448
The conversion of currencies in vouchers are made based on payment_rate_currency_id field (instead of usual currency_id).
This field was not present in the purchase view and not correctly set when we change the journal (and thus the currency) which was leading to rates of 1. With a rate of 1, the amount is equal to the currency amount (which is rarely correct). opw 611254
the new graph view silently ignored the context when doing its rpc
read_group. Usually, it's not really a problem, which is why it is only
now being fixed, but some models actually use the context in read_group.
(for ex, account_entries_report)
When a user tried to delete a done or canceled picking, the error messages used to display the key of the selection field ('done' or 'cancel') which was surprising in other languages than English. This patch takes the string value of the selection field, keeping the context to get the translated value (opw 613068)
When sending an email of the registration/confirmation, the context was lost and the tempate sticked in en_US.
With the patch, the template will use the current user's language.
Due to additional security rules, the transactions made as public user will have a new partner_id. The transaction needs to be retrieved as admin to be set in the context.
The operations in payment_get_status are made as superuser but the session_id is checked in the assert above to avoid url manipulation.
Do not allow everybody to access account.transactions.
Restrict by default to readonly and even restrict the access with a record rule, give access to salesman.
[FIX] sale: sale report view, wrong domain
Quotations are sale.order with state draft and sent
Sale orders are sale.order with state other than draft, sent and cancel
In this awesome programming language called javascript, undefined is neither bigger nor smaller than a string. Previous code was then considering undefined values equal to any string.
This fix allows to sort in a column of a o2m field and group the undefined values together. opw 607704
When a tax included has a several childs, the source line should not be duplicated for each tax.
Without the patch, the actual product price (without taxes) would be (total - tax amount) for the last tax only (and not the sum of each tax). (opw 609104)
readonly float fields in list view were not correctly placed when the focus was on the line (seen espacially if field was large, e.g. nb_register on registration)
To keep the pager and view changer after confirmation of a sale order, do not reload the view (quotation and sale order view are the same anyway)
Fixes#250
The attachment menu (list and add) has no effect in tree view (not supporting multi-items upload and display), the menu should then only be displayed in these view (opw 612534)