When "Filter by Periods" is choosen in the wizard, the right periods
must be set in ctx to filter the account moves according to the right periods
opw:674593
Backport of 8423a0df3482567b0e2f77852dda14b80a029401
Clear the cache/environment in addition to rolling back
the cursor, in order to retry the transaction with fresh
data, not partially stale data.
If a user syncs his calendar with Google,
and a second user is created in the database by copying this first
user, the Google information of the first user was copied
(The Google account to sync, the token to use, the last
syncrhonization date, ...), which is obviously wrong.
On calendar syncrhonization, which can be done
manually or automatically with the according cron, all
events of the first user were created a second time,
as a second user synchronized the same Google Calendar.
opw-674141
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 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
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
Without the proper decorator, the method is matched as `cr_ui_context`.
This is because the `guess` mechanism expects a name `res_id` instead of
`record_id`.
For stability reason it is better to add the decorator than modify the signature
of the method.
Closes#11735
This case corresponds to searches like `[(field, 'ilike', name)]` where `field`
is a many2many field. The domain processing performs a `name_search` on the
field's comodel, then makes the relation match the returned record ids.
Problem: the call to `name_search` uses the default limit (100), and this makes
the search return less results than expected. Make the search complete by
forcing `limit=None`.
This case corresponds to searches like `[(field, 'ilike', name)]` where `field`
is a many2many field. The domain processing performs a `name_search` on the
field's comodel, then makes the relation match the returned record ids.
Problem: the call to `name_search` uses the default limit (100), and this makes
the search return less results than expected. Make the search complete by
forcing `limit=None`.
When traversing relational fields as superuser, you end up with a recordset for
which only a subset is accessible to the current user. An earlier fix to this
issue completely dropped the `related_sudo` feature; change its implementation
to keep the feature.
When creating assets from invoice lines, the system must check
that assets have not already been created for the related invoice.
If assets already exist then these assets have to be removed.
Used case:
- In the purchase journal, tick "allow canceling entries"
- On a supplier invoice line, set an asset category
- validate the invoice
- cancel the invoice
- set to draft
- validate the invoice
Before the fix: the asset is created twice.
After the fix: the asset is created once.
opw:674674
The pricelist field is not a mandatory field on the partner. A default
value is usually defined for any new partner created. However, if the
pricelist is manually removed from the partner, errors (tracebacks) will
occur in the eCommerce when no pricelist is found.
We cannot make the field mandatory, as it could potentially break the
workflow of some users which are not using eCommerce. Therefore, we
simply log an error message to help debugging.
opw-673453
On the `res.company` model, the fields
`name`, `phone`, `email`, `website`, `vat` are
related field on the `partner_id` of the company.
When creating a new company, the partner
associated to the company is created automatically,
it's handled in the overrided `create` method
of the model, but it forgots the values
`phone`, `email`, `website`, `vat` at the moment
the partner is being created.
opw-675526
This fixes the case where the lines of a one2many field are modified several
times by onchange methods: instead of retrieving the most recent updates, we
merge them with former updates.
This solution was written as an improvement of a proposal made by Alexis
Delattre and Sébastien Beau as #11620.
When writting a value on a translatable field in a different language than
English, the submitted *raw* value was saved in the database.
This could cause the following issues:
- empty value (provided as `False` by the web client) saved as the string
'false' in the translations table
- no encoding or sanitization convertion
- ignore size parameter on the translatable field
Process the submitted translation through symbol_set method to clean it before
storing it blindly in the database.
This allows to convert `False` into `''` for empty value and fixes#10862
This revision corrects a regression introduced by
8395f0d217e16df18fcc6f4309fe74b0dd8d50a2:
the possibility to call
`ir.qweb.field.datetime`.`value_to_html` with
a datetime string directly, instead of calling
`ir.qweb.field.datetime`.`record_to_html`
(which call `value_to_html` as well).
opw-675427
The dates of an event on the website was always
within the user timezone. If not signed in,
it was within the public user timezone
(which is quite not user-friendly to change)
For this purpose, we weed get the context
from the record (the context used when using
`record.with_context`), and therefore
the QWeb field
`ir.qweb.field.datetime` is slightly altered,
to use the context from the record.
opw-675427
The stock history doesn't take into account internal moves. For example,
in the following situation:
- Receive 1000 products to Internal Warehouse 1
- Move these 1000 products to Internal Warehouse 2
The 1000 products are still recorded on the Internal Warehouse 1.
opw-672277
Oversight of commit bd025cda.
I'm an idiot, I should have checked that another solution was applied
from 9.0 with accounting refactoring. We apply it here as well.
When stock landed costs are divided per product unit, inconsistencies
may arise between the real stock valuation and the stock valuation
account. This is likely to happen when several products are bought, but
these products leave the stock one at a time.
A numerical example is the following: a landed cost of 15.00 is applied
to a purchase of 13 units. An amount of 15.00 is recorded when the
products enter the stock. If the product leave the stock one at a time,
13 entries of 1.15 are recorded (15.00/13 = 1.153846... ≈ 1.15), which
is then equal to 13 * 1.15 = 14.95. In this case, All the products have
left the stock (stock valuation is zero), but 5 cents remain on the
account.
This is of course even worse the higher the ratio is. For example, a
landed cost of 4.00 split into 1000 units sold piece by piece will never
be recorded when a product leaves the stock.
The fix is to record the rounding difference on a specific quant. In the
previous example, instead of adding 1.153846... on the unit cost of the
13 units, we do the following:
- 12 units to which we add 1.15 on unit cost
- 1 unit to which we add 1.20 on unit cost
opw-675222
When the product price is divided per product unit, inconsistencies
may arise between the real stock valuation and the stock valuation
account. This is likely to happen when a product is bought in a UoM
different from the standard UoM of the product.
A numerical example is the following: a box of 13 is bought for 15.00.
An amount of 15.00 is recorded when the products enter the stock. If the
product leave the stock one at a time, 13 entries of 1.15 are recorded
(15.00/13 = 1.153846... ≈ 1.15), which is then equal to
13 * 1.15 = 14.95. In this case, All the products have left the stock
(stock valuation is zero), but 5 cents remain on the account.
This is of course even worse the higher the ratio is. For example, a
box of 4.00 split into 1000 units sold piece by piece will never be
recorded when a product leaves the stock.
The fix is to record the rounding difference on a specific quant. In the
previous example, instead of adding 1.153846... on the unit cost of the
13 units, we do the following:
- 12 units to which we add 1.15 on unit cost
- 1 unit to which we add 1.20 on unit cost
opw-675222
The precision of `former_cost_per_unit` should not be set. Indeed, a
stock move can contain several quants with different unit prices.
Therefore, we should not round the field when stored, otherwise the
difference per unit will not be calculated correctly.
This is a workaround since we cannot change the DB structure in stable.
opw-675222