- 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
The field partner_id on stock.picking is not a required field so it
would possibly cause error when getting the name of the report since
partner_id was used in it since efdb5373c3.
opw-728549
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
Martin Trigaux