When you have push rules on move having a 'production_id', the
'production_id' is copied on the generated moves. So it generate a
traceback when we check the tracking method of 'product_id' on
produce_move.
This issue is caused because we get multiple produce_move instead of
one.
To fix this issue, we don't copy the production_id anymore on moves
generated by push rules.
In function _get_top_level_packages, when checking that all the products
have the same destination, the destinations must be stocked in a set
instead of a list because with different products it could return a list
with duplicated destinations.
opw:725720
- Create 2 companies (A & B)
- Create a product shared between companies
- Add a reordering rule in each company
- Add a supplier for each company
- Run the scheduler (from the cron)
The supplier selected is always the supplier with the smallest sequence,
since it is run in sudo mode.
opw-728346
- Create a SO with a product that is a service and will be invoiced
based in delivery quantities and will be tracked on timesheets and
contract.
- Confirm
- Use a simple user that only has for rights: "Employee"
- Create a timesheet as the employee for the contract created by the sale
- Log some time
- Save it
- Check the SO: ok the number of hours should be "to be invoiced"
- Edit the timesheet and set one day to 0 hours => Access Error
In case of a zero value, the timesheet widget sends an unlink command
for the corresponding entry. In this case, the `sudo` is not set at the
appropropriate moment since the context key `force_so_lines` will resue
lines which are not defined in the `sudo` environment.
opw-728453
Each REPL python shell behave differently depending on the exit method.
Force a rollback at the end to avoid inconsitent behavior.
Thanks to Harry Jollenbeck for the report: https://www.odoo.com/groups/59/26318707
SIPS payment has two limitations:
- A payment reference can only be used once, even if the payment was not
proceeded
- A payment reference can only contain alphanumerical characters
These limitations do not fit the payment process which:
- Reuses existing transactions
- Introduces a `-` character when creating a new transaction for the
same order.
First issue is solved by an ugly hack since there is no link module
between `website_sale` and `payment_sips` in order to override the
behavior of `sale_get_transaction`.
Second issue is solved by modifying the character to `x`. In this case,
we could consider overriding the method `get_next_reference` in
`payment_sips`. However, this method is called before the creation of
the transaction, and we should do a crappy workaround using the context
to get the `acquier_id`.
opw-728209
When you do a group by on field that is not present in the view,
this.fields contains all the model's fields, not only the ones present
in the view.
As we use the method 'has_active_field' to check if the field active is
available in the view, the value is not always correct.
To fix this we take the fields_view fields instead of fields.
This bug has been introduced in rev: https://github.com/odoo/odoo/commit/5b4f7c13f32f36d86805eb7865d8a077746181d8
- Create 3 products (A, B & C) with tracking set to 'serial'
- Create a BOM: A consumes 1 unit of B and C
- Create a MO for A, create the lot A1 for the finished product
- Create another MO for A, use the existing lot A1 for the finished
product
- Try to mark the MO as done => you get an error
- In the finished products tab, change manually the lot, for example by
creating A2
- Mark the MO as done
- Open the Upstream Traceability => under the MO, there is nothing, the
traceability is lost.
The `check_finished_move_lots` method takes care of setting the
`lot_produced_id` on the `move_raw_ids`. However, when changing manually
the finished product lot, this modification is not propagated.
Therefore, when posting the inventory (`post_inventory`), the line:
```
move_raw.move_lot_ids.filtered(lambda x: x.lot_produced_id.id == lot)...
```
doesn't return any lot. Consequently, `consumed_quant_ids` is empty, and
the traceability is lost.
opw-724944
In 599bd509 for inline image in a mail the `Content-Id` of the
attachment was used as the file name to avoir an issue of several inline
images with the same name only displaying the first one.
This solved the issue but with it the file name when downloading the
image were lost as well as the extension which can be an issue.
This changeset refactor the code so the behavior stay the same but the
original file names are kept.
opw-725305
Issue: when a field is computed on a new record, the record is not marked as
"being computed", and it could therefore be invalidated. The fix consists in
using the standard method that marks records before calling the compute method.
This commit prevents from erasing the origin part of the url
when the tour manager does a redirection. This was an issue in
phantomjs if it allows local url as in this case, it will try to
load file://<tour_url> instead of <origin><tour_url>.
- Create a product invoiced at delivery (A)
- Create a SO with Product A, confirm => the invoicing status is
"Nothing to invoice"
- Create a down payment => the invoicing status is "To Invoice"
Since the down payment is added as a product, its invoicing status
influences the global invoicing status of the SO, while it shouldn't.
opw-727936
The price of the product was not updated according to the pricelist
when changing the qty of a product in the cart because the context
of the product was not correctly set before calling function
_get_display_price in _cart_update.
But this part of code seems to be redundant with _website_product_id_change.
opw:728312
- Create 2 stockable products (A & B).
- Sell these products in the POS, but leave the qty of Product A to
zero.
- Validate and pay
- In the backend, return the products and register payment
Two pickings are created, and one of them is empty.
Products with a quantity of zero are not included in a picking.
Therefore, we should ignore them when the pickings are created.
Fixes#16292
opw-728101
We do not want to allow the change of a related config via a pos.order
and in case the pos.order is done or invoiced we should not be able to
change the user_id anymore and the fiscal position should never ever be
changed after the order is not in draft anymore.
User editable introduced at dca370d7.
Closes#16372
Steps to reproduce:
-Create a product P with a standard price = 0 and its internal category
is in perpetual valuation
-Create a SO with an analytic account and a line with one product P
-Confirm the SO
-Create and validate the invoice
Bug: The delivered qty on the SO was equal to 2 instead of 1 because two
analytic lines are created by function create_analytic_lines with amount=0.
So in function _compute_analytic, the domain was [('so_line', 'in', self.ids), ('amount', '<=', 0.0)]
and it summed the two analytic lines for these two lines. Now analytic lines with amount=0 and linked
to a move line are summed if the they are linked to entries for an account of type "Expenses"(user_type_id).
opw:727302
Step to reproduce the bug:
1.Create a product with a customer tax(15%) for a price=100
2.Create a customer invoice with this product
3.Change the amount of the tax to 10(instead of 15)
4.Validate the invoice
5.Click on "Refund invoice"
6.Select the refund method "Modify: create refund, reconcile
and create a new draft invoice"
Bug the new draft invoice has 15 as amount of tax
Now all the taxes from the invoice when preparing the refund in function
_prepare_refund, in this it keeps all the modified taxes.
opw:726491
Before the migration, send_mail() used to be called with an untainted
context but after the API migration it inherited the altered context
with active_test=False which caused subsequent calls to
ir.mail_server#connect() to fetch inactive records.
When no email is defiend on the partner, a traceback is raised when
paying with Authorize.net.
The `text` attribute requires a string, not a boolean (`False` in this
case).
opw-728301
When a user belongs to multiple groups, and an ir.rule is applicable for some of
them, the rule is added multiple times in the domain. Just do it once. This
makes the query shorter and easier to debug.
- Create a new account of type "Expenses". Allow the reconciliation and
assign this account on the internal category of a product on both
"Expense account", "Stock Input" and "Stock Output".
- Create a fiscal position to get the following tax behavior: apply two
taxes of the same amount but with opposite sign (+ 21% on the one
side; - 21% on the other side). Activate the tax cash basis feature on
these taxes. It should give, on the same FP:
Tax 21% -> Tax 21%
Tax 21% -> Tax -21%
- Create a journal for the tax cash basis, set it in the company
settings.
- Create a PO (with the previously created FP) for several products
belonging to the same internal category and receive the products. Each
line generates an entry recorded in the stock journal. The expense
account is used in those entries.
- Create the supplier invoice for the PO and validate which also
generates a journal entry with as many line on the expense account as
there are some products on the invoice.
- In the journal items, reconcile the expenses accounts entries
generated by the stock input and the supplier invoice.
It triggers a lot of lines on this expense account for 0 each.
opw-726120
Sergio Teruel Albert