The default account value set for purchases invoices
lines for product of type Service was wrong: It used
the stock account, which is wrong as a Service
as no stock. Instead, it should left the product
expense account, as usual.
opw-676110
Invalidate the cache of a x2many field when any of the fields appearing in its
domain is modified. Use the invalidation triggers mechanism for that purpose.
When invoicing products from a SO, you may decide to change the uom
of the invoice (if you invoiced only a fraction of the product, for
example). In that case, conversion is necessary to ensure that the
"invoiced quantity" field on the SO line is correct.
When a Google user was invited to one occurrence of a recurring event,
but not to the recurring event itself (and the other occurrences, therefore),
and the user owner of the recurring event did not sync his calendar in Odoo,
the event occurrence could not be synced in Odoo, because it attempted
to attach it to the parent/main recurring event, which was not present
in Odoo.
In such a case, Odoo now syncs the event occurrence as a simple classic
event. In addition, if the owner of the event sync his calendar with Odoo
afterwards, or if the user is invited later to the main/parent recurring event
and then sync again his calendar,
it then attach the event occurrence that was previously
synced to this main event, to avoid events duplication.
opw-676535
When clicking on save several time when editing a view form it can be
saved several times which can be an issue for one to many.
The normal happenstance when saving should be as follow:
-> save (click)
-> wait write result
-> received write result
-> reload the form with updated data and updates buttons
But when clicking several time, it could become:
-> save (click)
-> wait write result
-> received write result
-> save (click)
-> wait write result
-> received write result
-> reload the form with updated data and updates buttons
This commit only reinstate the saving feature once the form is reloaded.
closes#11926
opw-671793
note: no need to forward-port
When a user prints the GL of a given account, the GL of all accounts is
printed. On a production environment, this can generate thousands of
pages (and ultimately, a crash).
opw-676061
If the "NEW MESSAGE" or "Log an internal note" are clicked succeedingly
too fast, we can get into a situation where the composer is init'ed but
have not already been start'ed.
closes#11952
opw-675973
Used case:
-go as admin and set for the demo user the right "Settings" in administration
-connect as demo user, go in settings of project and untick the forecasts option and save
Result:
-Access rights error because the user has no rights to unlink records on "ir.values" model.
Fix:
When the user is in the group_system group, he has the rights to unlink records in "ir.values" model.
opw:676714
When removing the last line (apart from the delivery line) from the
cart, it is necessary to remove the delivery line before updating
the cart; otherwise the carrier is contacted with a 0 weight order
and crashes.
The user performing reconciliations may not always
have the right to update the corresponding partners,
for example if a partner is also a system user.
Doing it as super-user after verifying that the
user is indeed allowed to reconcile journal items
works around the problem.
Fixes#11931
When switching between records, the displayed thread was still the one of the
previous records until the messages of the current record were loaded, which
could be confusing.
Moreover, when quickly browsing records using the pager, it could happen that
the resulting displayed thread wasn't the one of the displayed record (if
we visited a record with a long thread history, the RPC to load that history
might return after the one of the current record).
This commit aims to always synchronize the displayed thread with the current
record, by
- directly hide the previous thread when browsing records
- displaying a spinner after 1s to indicate that the thread is loading and
(possibly) not empty
- ensure to only render the thread of the last visited record
The goal of this commit is to have better search results when fuzzy
searching. Before this commit, the position of a match was irrelevant
to the search results. After, a match in a first position has more
weight than a match in last position. This is better, because we often
want to find results using the first letters.
This is controversial, but I could not find a better way to do this
without rewriting the whole library myself (which might not be a bad
idea, it is only 50 lines long)
Damien Bouvy