The field was a stored computed field without dependencies, and therefore it
was never (re)computed. Add a simple dependency on the model `ir.model.data`
to make the recomputation everytime a view is modified. Moreover, when views
are created from modules, delay the recomputation of view fields until their
`ir.model.data` record is created.
On a PO linked to a purchase tender, changing the quantity on a PO line
will trigger a recompute of the unit price. However, this recomputation
will take into account the unit price of the supplier pricelist, not the
unit price on the purchase tender.
opw-690483
When the purchase tender of a PO refers to a blanket order, the price
unit used to create/update the order lines doesn't take into account the
potential difference of UoM.
The form widgets did not apply the 'style' attribute to the result of
the rendering. Because of that, many small adjustment were no longer
possible. This commit makes sure that it is indeed done.
This is required in order to have those bank journal items appearing afterwards in the bank statement reconciliation widget (blue line) for reconciliation.
This revert the fix made on 7bdd4de and replace it with a proper one that do create an account entry from stock_input to stock_output on a dropship move. That way, we avoid the manual change of account on supplier invoice. See the whole discussion on odoo#12687
Before this commit, the inventory by lot/pack/serial/... was only visible
if you switch quickly between res_config and adjustment inventory... once
the vaccumn clean the osv memory, the options was ignored.
Same issue with the _get_string_qty_information function.
Setting the value of a one2many field (`rec.line_ids = ...`) converts the new
recordset to a list of commands, and passes it to `write`.
Currently the list of commands is like: `[(5,), (0, 0, vals), (1, id, vals), (4, id), ...]`.
Notice that the command `(5,)` is inappropriate here: it deletes all the
existing lines of the record. Reintroducing the same lines with `(4, id)`
commands crashes, because the corresponding `id` is no longer in database.
The fix serializes the recordset as a list of commands like
`[(6, 0, ids), (0, 0, vals), (1, id, vals), ...]`.
Only the lines that are not kept will be deleted in this case.
- Create a deferred revenue type > 3 depreciations, one every month
- Create a deferred revenue with this revenue type
- Odoo generates a depreciation board with 3 entries > one should be
done in October, one November, one in december
- Generate your deferred revenues entries UNTIL 31st of december
Odoo create the 3 depreciations but they all have the 31ST of december
as accounting date > the dates of these accounting entries should be the
date defined on the depreciation board.
opw-690970
When we are trying to set the quantity on a mobile device, we get
a traceback saying that we cannot call the 'find' function on the
elements returned by '_get_records'.
This '_get_records' function returns a 'Collection' when called on a tree
view and an 'Array' when called on a kanban view. When we are working
on a mobile device, most of the one2many are displayed as kanban.
The thing is when we work with the object returned by '_get_records' we
call a 'find' method on it, which is implemented by Odoo's Collection class.
So when we call 'find' on an 'Array' we actually call 'Array.prototype.find' which
is implemented on most desktop browser and on some mobile browser [1]. This is what
caused the traceback on Chrome in Android.
To fix this issue, we enforce '_get_records' to always return an 'Array' and we ensure
that, when working on this 'Array', we use '_.find'.
[1] https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Array/find
In the frontend customer quote validation,
the company used in the sentence
```
I agree that by signing this proposal,
I accept it on the behalf of
```
was the quotation company, which is the company
which is selling, not the company/customer which is buying,
and this does not make any sense.
Instead, it should use the company of the customer
accepting the sales order, or simply the customer
if he does not have a company set.
The only case which make it a little weird is when
it's the customer himself, without parent company,
who is accepting the quote
"on the behalf of himself", but:
- This isn't possible to correct this without
breaking the translations, because the
sentence "I accept it on the behalf on"
is within the same sentence than
"I agree that by signing this proposal"
- This makes sense if another person than the
customer himself is validating the order
(the customer sent the quote link with the token
to another person).
opw-690837
Current issue without this patch:
On a bare database, install `website_portal` and go to `/my/home` logged out.
You get to an empty page where you can see Public User's details.
Expected behavior with this patch:
User should be redirected to the login page.
Additional notes:
- Other submodules (`website_portal_sale` and `website_project_issue`) were
actually implementing this, so that is removed BTW and relies in base
module's now sensible behavior.
This commit closes#12775
With this commit, it's now possible to set an arbitrary limit on any
kanban view by adding a limit attribut to the root kanban tag in a
kanban definition.
Do not forward-port.
Backport of rev 8a87c382ba
- Activate the receipt in two steps on the warehouse
- Create a PO for a stockable product
- Receive the product in Input zone
- Receive the product in Stock
- Reverse the move to Stock > products are back in Input
- Reverse the move to Input
You can't reserve quantities for this last move (from Input to Vendor).
This is because a picking has been automatically created from the Input
to Stock.
Original move which is reversed: Input -> Stock
When we reverse it, we don't want to send it back to Stock, so we need
to check the destination location of the original move, not its
location.
opw-689206
In the widget, the value of reference field is a pair `[val1, val2]`.
When the field is blank, its value is `[false,false]`, thus checking `[false,false] === false`
never succeeds, and this breaks the check for required fields.
This is done by guarding the `on_hashchange` evant handler with the
`clear_uncommitted_changes` function.
Note that the url has already changed when we are in this handler, so we
make sure to restore the old url when the user chose to continue its
edition.
When you browse through the views of an action and then hit the back button,
the view does not change. For example, go to the customers kanban, click
on a customer, hit back, you're still in the customer form view.
related rev: 46857d267b
`do_load_state` is called when you hit f5 or press the back button on
your browser. The related rev took care of fixing the ugly part that
make the webclient goes trough the multi record view then the mono
record view when you hit f5 on a mono record view.
In this context, it removed the code in view manager's `do_load_state` that
switched the mode of the action if it isn't the same the one the web client
is trying to restore from the state (because now the correct mode is loaded).
However, if you hit the back button while the previous view is in the same
action, it obviously doesn't switch the mode anymore and you're facing
the same view.
The issue is fixed by restoring the switch_mode in the view manager's
`do_load_state` (without its oudated comment).
Reconcile the following entries :
D C
Amount currency
3.655,52€ +3.872,45$
3.436,80€ -3.872,45$
What Odoo does when I reconcile the 2 entries above using the
"Reconcile" button:
D C
Amount currency
3.655,52€ +3.872,45$
3.436,80€ -3.872,45$
0€ 218,72€ -236,61$
0€ 0€
+236,61$
What Odoo should do :
D C
Amount currency
3.655,52€ +3.872,45$
3.436,80€ -3.872,45$
0€ 218,72€ 0$
opw-687481
Like in Invoices Analysis, the expenses must be expressed in the currency
of the company. In this way, it makes sens to sum them to compute the total.
opw:689760
The effect of this change is to trigger the recomputation of fields on larger
recordsets. This takes advantage of batch computations within compute methods.
For the field account_depreciation_id in the account.asset.category.form
view, the string "Depreciation Expense Account" was already used for
the field account_depreciation_expense_id.
opw:690297
When creating a SO line and an invoice line for a downpayment,
the fiscal position set on the SO must be taken into account
to map the right taxes.
opw:688611
when extending these methods with the new api, the context is a frozendict
so we need to copy before mutating.
this patch was made by searching for key addition to context and calls to the
update() method on the 8.0 addons, and checking if a copy was made before in
the method.
Using the read method should generally pass a single id as a list
due to the new API inheritance of the read method. If an attempt
is made to use the new API, the result is inconsistent.
Following 4f0ca6d9Closes#13678
The validation_date was using the creation_date value in the follwing scenario:
1. create a new order with a few lines (creation_date=t1)
2. reload the page, `init_from_JSON` uses validation_date=t1
3. validate the order at t2, ignored due to already stored value
creation_date must be kept for tracablity reasons (e.g. pos_blackbox_be)
Fixes https://www.odoo.com/groups/59/20542134
The field in stock configuration group_stock_adv_location is toggling
the group "stock.group_adv_location". There was a typo which was using
on the form view of purchase.requisition the group
"stock.group_stock_adv_location" instead.
opw-690804
Raphael Collet