So that was a fun one: mock.patch calls would regularly fail refusing
to find the addon in odoo.addon (e.g. essentially getattr(odoo.addon,
'account_budget' deep within the bowels of mock).
Turns out the answer is that our import hooks would not be used for
many imports: while in Python 2, sys.meta_path is empty and the
default finders are run after all meta_path finders fail as noted by
the documentation[0].
However when the import system was rewritten in Python 3.3[1]
meta_path was "despecialised" and the default finders were moved to
meta_path rather than be a hidden part of the import machinery[2]:
> sys.meta_path and sys.path_hooks now store all of the meta path
> finders and path entry hooks used by import. Previously the finders
> were implicit and hidden within the C code of import instead of
> being directly exposed.
The result of this change is that ``sys.meta_path.append`` means the
default finders should take priority and the custom ones should be
fallback. This is the exact opposite of what we want.
Fix issue by ``sys.meta_path.insert``-ing our finders at the start of
the path rather than appending them at the end. This should change
nothing in Python 2 but seems to fix the issue in P3.
[0]
https://docs.python.org/2/library/sys.html?highlight=meta_path#sys.meta_path
[1] https://docs.python.org/3/whatsnew/3.3.html#importlib
[2] https://docs.python.org/3/whatsnew/3.3.html#visible-changes
https://bugs.python.org/issue13936
That's a pretty sensible change, but it turns out we did have some
bits of resource which implicitly depended on the old behaviour.
In Python 2, hasattr swallows *any* exception raised during the
access. In Python 3, it only swallows AttributeError.
Accessing an attribute on an unbound threadlocal proxy raises
RuntimeError, while running test_ir_http_mimetype ``request`` is
unbound, in Python 2 ``hasattr`` would return ``False`` on an unbound
threadlocal, in Python 3 it lets ``RuntimeError`` pass through blowing
up the test.
Fix this by just checking if the threadlocal is bound by using it as a
boolean…
In Python 3 round:
* rounds half to even (banker's rounding) rather than up
* returns an int if not given a precision (or given a precision of
None)
* discards the negative sign when rounding to 0
Add a compatibility shim which implements P2 behaviour and at least
allows passing float_utils's tests.
Implementing float_round on top of Decimal was attempted but did not
work: although Decimal.quantize takes a non-integral
Decimal (e.g. ``d.quantize(D('0.001'))``) it only supports integral
powers of 10 and does not support quantizing to e.g. 0.05: while that
will not fail it will just use the exponent for quantization and 0.05
is thus equivalent to 0.01, which is not what we want if e.g. need to
round a value to 5 cents.
This is hinted at but maybe not clearly spelled out by the official
documentation:
> Return a value equal to the first operand after rounding
> and **having the exponent of** the second operand.
Also convert a bunch of hand-rolled currency rounding to just using
the round() method on res.currency.
Commit 3e3105151b removed the portal module as its feature are completely
replaced by front-end customer portal or base portal user support in various modules.
However the portal pot file, kicked out of Odoo by the door, tried
to come back through the window. This commit closes the window and
puts this file out again. Let us hope it does not make holes in
the garden or barks at neighbors.
Steps to reproduce:
1.Create pos order with two products.
2.One of the products, must be type="Stockable Product" and quantity=0.
3.Pay order.
4.Check order --> extra info --> picking
Bug:
picking state = Waiting Availability
In 9.0, the picking state is equal to "Done".
Fixes#18089
opw:751565
Base render method now calls a prepare_qcontext method used to prepare
the qweb context used for the rendering. Website override of ir_ui_view
now simply inherits this method to add its own set of values instead of
doing strange things with the base render override.
Qweb context should be the same after this commit, i.e. containing a lot
of duplicated things like a copy of the context. The only change is that
user_id and res_company are now directly supported in base rendering
instead of only in website version of rendering. Future commits will
use those values.
Calling super when it is possible it always a good practice. It ensures
to have a basic behavior that is the fallback when the behavior defined
in the inheritance does not apply. Previously the base behavior was done
directly in the inheritance without calling super. This commit improves
that and calls super like a pro.
As this field is defined directly in payment and is displayed on
acquirer form view let us display it in tree view also directly
in payment instead of website payment.
This is a manual forward-port of commit 5f24bf5df7.
As this field is defined directly in payment and is displayed on
acquirer form view let us display it in tree view also directly
in payment instead of website payment.
When unlinking payment terms, the ir.property records linked to
the fields "property_payment_term_id" and "property_supplier_payment_term_id"
were not deleted.
opw:749459
Updating the partner of an SO imply
* setting the new partner sales person if set;
* setting myself as I am the person who updated the SO and is therefore
in charge of managing it.
If the new project of the task or issue has the current record stage
among its own stages do not reset it. It avoids unnecessary changes and
chatter logs.
The accounting date is an hidden field, which is by default the invoice
date. However, a user can make it available in the interface, and modify
it.
When the accounting date is different from the invoice date, we must
make sure to make the accounting date prevail when it comes to currency
conversion. Otherwise, the account move created will use a currency
exchange rate which is not in line with its date.
opw-751848
Purpose
=======
When generating `Cash` bank journal on CoA import, it doesn't makes sense to have the `Check` payment method enabled by default
Specification
=============
When system automatically creates journals of bank and cash type when CoA is being installed,
1) type = "Bank"
- Manual -> Checked
- Check --> Checked
2) type = "Cash"
- Manual -> Checked
- Check --> Unchecked
Since the new views, `record.id.value` contains the formatted value of
the ID, meaning it can contain separators. For example, by default,
`1234 => 1,234`. Since this value is used in the image URL, using
`value` won't work anymore.
See commits for more informations. We consider the model as almost
OK, but were are aware that we are introducing all kinds of new
bugs and we'll do our best to fix them quickly :)
lifo_price.yml:
- change the cost method to fifo, as real price does not exist
anymore
- do not check the standard price, as it is not update on the
product in fifo
- correct calls to picking
- end the test by checking the value of the out move
- note: testing the lifo removal strategy has not effect here (we
could adapt the test to set lot on receipt and check that the
right lot was taken, but we didn't to that here)
* If the user tries to decrease the quantity of a sale order line below
the received quantity, we raise a warning telling him to create a
return first.
* As we do not propagate the decrase to the already created pickings, we
post a message in the chatter of these pickings informing the pickers
of the change.
The new implementation of stock moves the cost of products from quants to
moves. So we have implemented the FIFO and average cost method based on
those moves instead of using quants.
- When average price is choosed, a field average_price is set on the
product.
- The tests have been completed with an example of how fifo work with
negative stock.
As the use of real price method is really rare, because of the rigor
required on traceability for such method, we removed this functionnality.
- The tests purchase/test/fifo_price.yml have been adapted to use the
FIFO costing method instead of real price.
The old report stock history doesn't exist anymore, and is replaced by
the move view that contains all the cost information.
The methods `get_price_unit` have been moved from the stock to
stock_account.
The methods `_set_default_price_moves` and
`set_default_price_unit_from_product` have been removed from stock.
Explaination of FIFO and average:
- In action_done for an out move in average and fifo, the price_unit and
stock_value are updated.
- For FIFO, it will use the qty_remaining on the in moves to check from
which in moves to take the stock values for the out.
- In case of negative stock in FIFO, it puts also qty_remaining on OUTs.
- In the case of average, it will take the cumulated value of the last
move and divide it by the quantity in stock.
This commit is pretty much a 'work in progress':
- Edit 'done' moves when the costing method is FIFO doesn't trigger the
replay the FIFO stack.
- The landed_costs feature doesn't work.
This commit adapt purchase to be able to edit purchase line ordered quantity
and propagate it to the related picking after the request for quotation
validation.
These are the supported use case
- When you increase the quantity on a purchase line, an extra move (and
an extra picking if they are all done or canceled) is created with the
difference between old and new value and the push rules are applied on
it.
- When you decrease the quantity of a purchase line, different behaviors
can occurs:
* If you plan to decrese the ordered quantity under the received
quantity, you get a user error saying tht you have to make some
return before.
* Else the moves not done or cancelled are decreased by starting with
move having no procurement_id. The decrease is not propagated
through push or pull rules.
* If you decreased the quantity under the invoiced quantity, a next
activity is created to remind you to do a refund.
Xavier Morel