Have a product that is an event, with the price of 1500.
Create a ticket for this product in an event, with the price of 600.
In a SO, add a line with this ticket.
Before this commit, when you change the tickets qty in the SO the price
change from 600 to 1500.
Now, the unit price stays the one of the ticket.
opw-1940368
In 187c32c2 some improvements were made for conserving/restoring group
bys on the pivot view.
This introduced an issue on the column group by:
- before reload, if we set manually a column group by (+ icon in the
header) it would be saved and not lost (unless a context or filter
in the search view override it)
- after reload, the following manually set column group by are not saved
anymore on subsequent reload (the column group by at the first reload
are set back)
This behavior is not normal since the behavior (conserving or losing
column group bys) should be the same at first reload or second reload.
The issue was caused by the duplication of group bys that were not
synchronized (one on the column root header, one on the pivot model
instance).
Without the change, the added test failed with: "Column groupby not lost
after second reload" and product_id is hidding from the object
pivot_column_groupby dictionary (having only "customer").
Using _.clone on initialRowGroupBys was necessary change because without
duplication of "groupbys", the initialRowGroupBys would be changed on
expandHeader which is unexpected.
opw-1941095
closes#31407
[FIX] models: do not erase master version
For a translated field with a callable method (e.g. xml_translate), when
modifying the value of this field in another language than en_US, the master
version was lost.
Before this patch:
>>> record.arch = "<h1>Title</h1>"
>>> record.with_context(lang='fr_FR').arch = "<h1>Titre</h1>"
>>> record.with_context(lang='fr_FR').arch
"<h1>Titre</h1>"
>>> record.arch
"<h1>Titre</h1>" # lost English version
After this patch:
>>> record.arch = "<h1>Title</h1>"
>>> record.with_context(lang='fr_FR').arch = "<h1>Titre</h1>"
>>> record.with_context(lang='fr_FR').arch
"<h1>Title</h1>" # write had no effect
>>> record.arch
"<h1>Title</h1>"
When modifying a translated HTML field in English, a matching to detect the
difference and avoid losing the translations is done.
This is not supported for update in another language.
The main reason is the difficulty to detect changes in the architecture.
To update translations, the supported way is to go to the list of translations
and update them there.
Before this patch, the given value in another language was given to the SQL
query and made an update in database:
if single_lang or not (has_translation and field.translate is True)
-> True or not (True and False) -> True
If a field is callable, it should also be ignored, the same way than
translate=True fields
opw-1887162
closesodoo/odoo#31451
Before this commit:
-> Debug mode
-> Settings
-> Database structure
-> Fields
-> Any selection field
=> The field `selection` of the ir.model.fields form view does not
display the selection options of the field being viewed, this is because
the selection field is not registered at `_reflect_field_params` of
`ir.model.fields`.
After this commit:
The field is properly registered; for Selection fields with static
options, these are shown as-is, for fields with a lambda function as
options, the string 'function' is displayed, and for fields using a
function name as a string, the same string will be displayed.
Fixes#28360closesodoo/odoo#31207
Modify the suggested products of a quote template
Before this commit, the description of the line was only filled with the
product name
After this commit, the sale description is included
OPW 1945131
closesodoo/odoo#31425
Before this patch, if an m2m's relation field pointed to a model that
was to be deleted, the deletion of the aforementioned model wouldn't
trigger the m2m's deletion, which would lead to the registry crashing.
With this patch, whenever an ir.model is being unlinked, a check is
performed to verify that no other fields (m2m or otherwise) have this
model as a comodel, and if they do, they are unlinked as well.
closesodoo/odoo#30230
When getting the context of res_users, all the fields are read but if
the schema is being modified and the modifications are not yet commited
in the database, this leads to a bad query.
With this commit, a read is used to fetch only the needed fields.
Thanks to @RCO for finding this issue that only occurs in specific
planetary alignment.
closesodoo/odoo#27263
* Create a new invoice and validate it.
* Create a new bank statement, without having the partner filled in.
* Reconcile the bank statement to the invoice.
* Open the generated payment.
Before this commit, the field partner and partner type are empty in the
payment.
Now, the field partner is filled with the invoice's partner, and the
field partner type is calculated.
opw-1917028
closesodoo/odoo#31399
- Create 2 companies C1 (USD) and C2 (EUR)
- Create 2 products P1 and P2
P1: company: C1; cost: 50
P2: company: C2; cost: 50
- Make sure to define the cost in both companies since it is a property
field (set it to 50 in all cases)
- Update the currency rates for both companies
- Create a pricelist in EUR, with a price based on the cost price.
- Create a SO in C1, select the pricelist previously created
- Add P1 and P2
The unit price for P1 is converted, while the unit price for P2 is 50.
This is not correct: both cost prices are set to 50, so the unit price
should be identical.
This is because the pricelist always assumes that the price retrieved is
in the product currency. In this case, this is not correct: the price
retrieved is in the company currency, since the cost price is in the
company currency.
Closes#30616
opw-1934443
closesodoo/odoo#31402
The cost of the product is a property field, meaning that:
- its value depends on the current company;
- its currency is the company currency
However, several views use the monetary widget to display its currency
with the default `currency_id` field. This can be incorrect, since the
latter is computed based on the product's company.
We introduce the new computed field `cost_currency_id` which has the
appropriate value and can be used in the views.
Closes#30616
opw-1934443
Usecase:
- Create a planned transfer
- Add line with initial demand
- Create a scrap
- Click on button validate
The wizard asking for a backorder or not is diplayed. The UserError
that prevent to validate a picking without quantity done or reserved
should have been raised. The scrap moves are directly processed once
the user validates his scrap order. Validate a picking with only done
moves, will not have any effect.
closesodoo/odoo#31076
Usecase to reproduce:
- Create an internal picking from stock to scrap
- Add some scrap move inside due to scrap button in header
- Add some move with initial demand for future
- Mark the picking as done and validate it
- The wizard asking for a backorder appear -> Validate or No backorder
The moves with initial demand are duplicated(one new move for each
without intial demand nor quantity done)
A note is logged in the chatter with backorder False has been created.
There is a problem since _action_done on a scrap move from scrap model
will process the scrap move individualy but will create a back order
(commit e088acbc0f try to fix this issue)
However when we create a picking that goes to scrap location, the back
order will not be created since all moves are scrapped.
With the current configuration we can't guess in _action_done if
it comes from scrap or picking validate that goes to a scrap location.
The current solution is to use a context key in order to indicate if the
call come from picking validate or scrap. If it comes from scrap do not
create a back order no matter the case. If it comes from picking, follow
the standard beahvior with a backorder or not.
opw-1934835
Before this commit, the t-lang on a t-call was not
propagated into the context's of the callee template
It resulted into mismatch translation and formatting in the final
rendered template
i.e. having a t-esc with a qweb widget float would take the wrong float format
After this commit, the t-lang parameter alters the context of the template
and t-esc with widgets are translated
OPW 1939989
closesodoo/odoo#31291
Have a partner which is a company, with some children
Click on the action "Portal Access Management"
Before this commit, only the children of the company is selectable in the wizard
but not the company itself
After this commit, the company is part of the list
OPW 1931920
closesodoo/odoo#31344
compute_sudo has no effects on non stored computed fields.
It was technically already said in the previous lines (REcomputed) but
it was not particularly explicit
closesodoo/odoo#31320
compute_sudo does not do anything when the computed field is not stored.
This fixes an issue where user not part of base.group_erp_manager
couldn't modify res.partner
opw-1942803
On a pivot view with a default filter which has column and row groupbys
Remove the filter
Collapse all columns and rows
Activate another Filter from favorite which has a column groupby at least
Before this commit, the columns were not displayed in the DOM, though RPC's
and internal data were actually correct
This was because we considered the changes had been done "in place"
taking the old tree to build the new one for the columns
when really, we should have recomputed the column tree
After this commit, the columns display the group we want
OPW 1935155
closesodoo/odoo#31247
currently, if the user wants to refund amount to the customer
and enter negative payment form keyboard its throws an error. that will fixed.
Task: #1935602closesodoo/odoo#31061
After discussion with the Mighty Priestess, the address used in the
Delivery Slip should be the picking partner as a first priority, then
the move lines partner.
And we therefore remove the useless 'Assign Partner' button (but not the
associated method since it is public).
opw-1935039
closesodoo/odoo#31250
_reverse_move presents a critical performance issue when
unreconcile moves with a lot of account_move_line.
The issue is that `account.move` and `account.move.line` models are triggering computed fields/methods for each new
`account.move.line` added, computing all lines again and again.
Making a factorial performance issue.
For each line the function try create cash basis entries for tax/base lines and this is combined with all the
fields compute that exists on the model so this introduce a performance problem
The issue is that `account.move` and `account.move.line` models are triggering
computed fields/methods for each new `account.move.line` created isolated,
computing all lines again and again.
e.g.
_compute_matched_percentage at
https://github.com/odoo/odoo/blob/5e8289cfeaf52a1eac64bcc975b186f0b5f9594b/addons/account/models/account_move.py#L44-L62
Then for each line modified/created this compute is executed for all lines (not just the last one).
Now by using self.env.norecompute() and self.recompute() the problem was reduced.
Unreconciling an 'account.move' with 1576 lines with a payment takes almost 4
minutes when before this changes, the conciliation process seemed not to never
end.
Fix https://github.com/odoo/odoo/issues/30934closesodoo/odoo#31014
create_tax_cash_basis_entry presents a critical performance issue when
reconciling moves with a lot of account_move_line.
The issue is that `account.move` and `account.move.line` models are triggering computed fields/methods for each new
`account.move.line` added, computing all lines again and again.
Making a factorial performance issue.
For each line the function try create cash basis entries for tax/base lines and this is combined with all the
fields compute that exists on the model so this introduce a performance problem
The issue is that `account.move` and `account.move.line` models are triggering
computed fields/methods for each new `account.move.line` created isolated,
computing all lines again and again.
e.g.
_compute_matched_percentage at
https://github.com/odoo/odoo/blob/5e8289cfeaf52a1eac64bcc975b186f0b5f9594b/addons/account/models/account_move.py#L44-L62
Then for each line created this compute is executed for all lines (not just the last created one).
Now by using self.env.norecompute() and self.recompute() the problem was reduced.
Reconciling an 'account.move' with 1576 lines with a payment takes almost 4
minutes when before this changes, the conciliation process seemed not to never
end.
Fix https://github.com/odoo/odoo/issues/30934
In some exceptional circumstances, the computation of the remaining
leaves might lead to numerical errors, e.g. a very small but non-zero
number (e.g. 10^-17)
This value will be displayed in the name of the leave type because of
the `%g` used in the string format. To avoid breaking the translation,
we round the value.
opw-1935232
closesodoo/odoo#31245
When defining an ABA routing number with leading zeros (which is
possible), the value will always be displayed without them.
This is because the field is an integer. Since the ABA routing transit
number must be a nine-digit code, we automatically fill it with leading
zeros.
opw-1940138
closesodoo/odoo#31223
- Enable multi-currency. Company currency = USD, another currency = SGD
- Update the exchange rate
- Create a purchase journal. Assign SGD to this journal
- Create a purchase tax of 7.00 %
- Enable tax rounding globally
- Create a purchase receipt with the following values
62.04 @ 7% tax
7.29 @ 7% tax
An error occurs: 'Cannot create unbalanced journal entry.'
Each line of the receipt creates its own tax line, which is therefore
rounded => the total of the receipt is computed with a 'round globally'
configuration, while the taxes are computed with a 'round per line'
configuration.
This is because `apply_taxes=True` is set in the context. This creates
the tax line by forcing the rounding. Therefore, we call the method
`_apply_taxes` explicitly in this specific case, and manually round the
taxes once they are merged.
opw-1938623
closesodoo/odoo#31194
We extract the tax creation from the AML creation in an external method,
in order to be able to call it separately.
This is necessary for the subsequent commit.
opw-1938623
Before this commit, when new messages were posted in a new
livechat, the operator received them after a delay. This
may take up to a minute before receiving the notification.
This behaviour was causing a bigger issue: those notifications
may never be received by the operator. This case happened when
the operator was receiving more recent notifications while
notifications from new livechats were pending.
The delay was caused by the operator not yet subscribed to
notifications on the newly created livechat. It is only on
the next poll of longpolling that the subscription occurred,
then followed by dispatching the notifications to the operator.
This commit fixes the issue by dispatching new messages of new
livechats directly to the operator. This is done by enforcing
the operator to make another polling when a new livechat is created,
so that he is always subscribed to those livechats. As a result,
new messages are received instantaneously.
opw-1933951
closesodoo/odoo#31191
In Odoo, create a user John@example.com (the cap is on purpose)
In Google Calendar, create an event and invite john@example.com
Sync your Google calendar.
Before this revision,
the event created in Odoo did not add John@example.com,
but created a new attendee, john@example.com, because
of the sensitive casing.
Besides, give the priority to partners having
users, so if there are two partners with the same email,
one of them having a user,
e.g. John@example.com (with user) & john@example.com (without user),
set the partner having the user as attendee,
as its the one with the user who use the Odoo calendar,
and potentially the Google sync as well.
opw-1925592
closesodoo/odoo#31111
In some case, when the user enter by mistake an account move line
with an amount of 0,the reverse operation does not works properly.
The issue happenned during the reverse operation because it tries to
reconcile a 0 account move line with no matches (credit or debit).
See opw-1931961
Before this, groups on non-stored inverse fields were not checked upon write.
The impact on existing fields is pretty small, since the inverse methods of
those fields are subject to access rights on the records they use.
closesodoo/odoo#30356
This is the first step to a more comprehensive handling of company-dependent
fields which are ir_properties.
With model-specific access rights, users should be able to read/update a
company-dependent field no matter their access rights on ir_property.
Before this commit, a user having access to res.partner, but not to ir.property
couldn't write on property_account_receivable/payable just because he couldn't
write the corresponding ir.property. After this commit, he can.
OPW 1923345
Jorge Pinna Puissant