Before, the '_set_quantity_listener' function was opening a 'window.prompt'
which had different comportment depending the navigator. For example,
the focus was not allways on the input field, the enter key 'Cancel'
the prompt or 'validate' it.
So to improve the usability and the consistancy we used a dialog instead
a prompt, to manage the focus and the 'Enter' key pressed when we want to
set a quantity.
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.
When the user clicks on the stat button to access the partner invoices,
the invoices are not displayed.
This is because the domain is wrong.
Fixes#13883
When a account statement is validated, it's not possible to cancel a statement line.
To cancel a line from a validated statement, you must first reset to new the statement.
In this way, it's not possible to have a validated statement with unreconciled lines.
opw:690766
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.
When returning an item by entering an orderline with a negative quantity
you got a warning message asking you to confirm a large payment
amount. Introduced by 5a3d9ce9ce.
Closes#13777
If you validate an order it will be sent to the backend. If you then
close the POS frontend somehow before clicking 'Next order' this order
will be reloaded from localStorage when reopening it. This is
problematic because it allows the user to then modify this order and
validate it again. Everything will appear fine but in the backend this
new, modified order will be ignored as it has the same pos_reference as
the one that was sent initially.
The deeper underlying issue is that there exists a brief timeframe where
the same order can exist twice in the db: both as 'order' and
'unpaid_order'. To ensure this does not happen this fix removes the
order from the unpaid orders after it is saved as a validated order.
Fixes#13538
This way you don't have to wait the 5 seconds, or click the "ok" button
to return the the kiosk mode to be able to scan the next badge.
Note: listener is disabled if a warning message is displayed.
+ small code/comments cleanup
Before the fix, the tax base amount is computed only for a complete
invoice line. However, depending on the tax sequence and their inclusion
in the base amount, the tax base amount might be different for the
various taxes of an invoice line.
We keep track of the base amount for every single tax, and refactor the
`_compute_base_amount` to take these values into account.
opw-691177
Closes#13819
Recent refactoring of the parallax changed the snippet option JS and
attached a callback on a editor element but forgot to detach it if
the parallax snippet is removed. This added a bug which broke the
editor every time a parallax snippet was removed.
When registering a payment on an account invoice with an automated
action which adds a follower "On Creation & Update", the function
recompute was triggered(due to the field residual_company_signed)
and the same followers was added two times for the invoice.
The fix avoid to unlink and create the same followers several
times(because it was the case with the function "_add_follower_command")
opw:690939
Before this commit, the one2many widget was not displayed if no data.
That make some form (notebook) empty while the user don't click en edit to see the widget appear.
Eg: stock picking 'Initial Demand' tab
Courtesy of @ged-odoo
Before this commit, create a blog post since the backend raise
an error because the post_date is False.
It should never arrive, since it is a compute field that is the
publish date or fallback on the create_date.
But because set post_date, change the published_date, the depend from
publish date cannot be triggered again since it change the post_date.
So _set_post_date don't trigger _compute_post_date. And call it manually
will make 'max recursion depth python'.
The 'hack' to update publish date, without retrigger the _compute_post_date
and set post_date manually, is to use the _write method that don't trigger
all depends fields.
Courtesy of @rco-odoo
This commit closes#13829
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.
The following configuration leads to different results:
- Deferred revenue: 12 entries, 1/month, prorata temporis, 1000€,
date 15th of October
- Asset: 12 entries, 1/month, prorata temporis, 1000€, linear, date
15th of October
Deferred revenues and assets should give identical results.
opw-690034
Martin Trigaux