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.
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.
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.
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
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.
We adapted the views to the new stock model, and differenciate two
different views:
- The first one is more adapted for simple operations, or when no
suggestion of location, lot, pack is needed. We have a line with
the initial demand of each product and you can complete the lot
numer, location, etc in the detailed window of a move.
- The second one is more adapted for pick and barcode operations, all
each line is fully detailed with the system reservation, you can see
the lot, location, etc you must scan in the list view.
You can choose the view you want to use in the picking type settings by
check the box 'Show Operations'
The big change is that we have now a many2many between the move and a
one2many between a move and its pack.operation (note: this model is
renamed as stock.move.line in a further commit).
Due to these changes, `action_done` had to be rewritten intierely, as it
depended and stock.pack.operation.lot and stock.move.operation.link,
that are now removed. This method was laregly inspired by the one in the
mrp module, and a further commit will make MRP uses all the core of
stock.
Due to the previous commit that refactored the stock.quant
implementation, the new concept is that the `product_qty` that will
always be in the uom of the quant (`product_qty` is a computed field in
the same style as the one of stock.move).
This commit also implements the logic that a manager is able to edit
done stock.pack.operation.
The stock.move has now a "partially_available" state (it was previously
a flag). The "split_from" field is removed now that we have a many2many
between moves (a sibling move is always a move that was splitted, or
with the backorder_id field).
The done quantity of a stock move is computed across the done quantity
of the move lines. There is an inverse method that allows user to fill
the done quantity directly on a stock move.
The reserve quantity of stock move is computed accross the
`product_qty` of the linked pack operations.
`do_unreserve` will simply unlink the associated pack operation.
Unlinking a pack operation will unreserve.
`force_assign` will mark the move as available, in order to allow the
user to create pack operations (none are created because nothing was
reserved).
`action_assign` is rewritten and splitted in two parts: if the move has
a parent (mto) or not (mts). In the mto, we'll check the available move
lines and only reserve accordingly. In the mts, we'll reserve directly
on the quants.
`action_cancel` has changd a lot: in case of a delivery, the first step
does not anymore propagate cancellation to following moves and SO. As a
result it does not propagate in the other side in case of MTO or production.
It does not delete them if we delete the related sale order for example. In
order to correct this next activities will be added in the future. Technically
action cancel on move is based on procurment rule, this commit will set
the propagate field to false on the rule if the picking_type is 'pick'
or if we are in one step delivery.
We use this commit to reimplement `action_assign` (wiped by the new
quant implentation). A move is reserved if its move lines exist, so we
introduce a one2many between stock.move and stock.pack.operation (note:
a further commit renamed this model into stock.move.line)
We use this commit to implement `action_done` (wiped by the removal of the
models making the link between stock.move and stock.pack.operations). We
can use the one2many to the pack operations.
blabla manymany au lieu de one2many
blabla mto mts
Remove get_ancestors, as orig_ids will be used instead
validation
when we are creating some packe operation with lot name, the
pack_operation are unlink and a new picking is craeted.
This is caused the function _create_lot_for_picking that unlink pack
operation having no quantity reserved instead of ones having no quantity
done.
To fix this we changed product_qty to qty_done and move the code from
action_done of picking to action_done of move
fixup! [IMP] Merge_moves functionality + many2many procurement and original moves instead of one2many
fixup! [REF] stock: basics of new model and stock.move reservation
edit reserved move line
This is the 1st commit message:
[REM] stock: stock.pack.operation.lot, stock.move.operation.link
These models will become useless once a one2many will be made between
stock.move and stock.pack.operation.
The `action_done` method on stock move has been wiped, as it depended
completely on the removed models.
Joint work with Josse Colpaert <jco@odoo.com>, amoyaux <arm@odoo.com>
and Pierre Masereel <pim@odoo.com>
The main idea of this new implementation is that stock.quant is now a
cache of the quantity per location/lot/pack/owner key. We removed every
identity per record, such as `history_ids` or `inventory_value` so that
we can now avoid the linear creation of stock.quant records and are able
to work with only one record per key.
The algorithms to retrieve the quantity per key are made to work with
multiple records, this way we can implement strategies to workaround
postgres locks if concurrent transactions try to work on the same quant
row.
Quants will not be linked to moves anymore, this is in order to be able
to edit stock moves more easily/freely. We removed the links with this
commit and wipe out the `action_assign` on stock move. This will be
implemented in a followup commit, once the relations between stock.move,
stock.pack.operation and stock.quant are clarified.
This commit seems to have unecessary diff, but it was done in order to
run tests on the new implementation.
We adapt the views by removing the fields not present anymore in the
model. This include the complete removal of the inventory valuation
view, as the implementation of stock valuation will be refactored and
moved on stock.move in a following revision.
We wipe out `action_cancel`, `recalculate_move_state`,
`move_quants_by_lot_v10` and `quants_unreserve`.
* `get_removal_strategy` moved from `stock.move` to `stock.quant`
Stock quant model:
* qty renamed to quantity
* history_ids: because the quants are not moved
* inventory_value: implementation moved to stock.move
* packaging_type_id: doesn't seem to be used (in filters?)
* propagated_from_id: because we do not split forced quants
* reservation_id: because the reservation are not linked to
the stock.move.line
We remove the `lot_ids` computed field, as it depended on the link
between stock moves and quants and could be replaced by a related
to the move lines once the new relation between stock.move,
stock.pack.operation and stock.quant is clarified in a further commit.
Furthermore, the field was not displayed to the user.
Xavier Morel