It seems that our beloved administration is not happy with the FEC file
ending with an empty new line
Hence, this commit makes the FEC file last line end without \r\n characters
and there is no empty new line
OPW 1943302
Before this commit, a pricelist discount based on the product qty could
be created and the user may believe that it will work also for event
tickets.
Now: when configuring a pricelist discount based on the product qty a
warning message is show to alert that this kind of discount don't work
in event tickets.
opw-1940368
closesodoo/odoo#31459
Signed-off-by: "Lucas Perais (lpe)" <lpe@odoo.com>
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 product, to another product that
is also an event, the event, the ticket and the price stayed the ones of
the first product.
Now, the event, the ticket and the price are updated when the product is
modified.
opw-1940368
Werkzeug version was being checked to avoid passing quote=True to
werkzeug.utils.escape (as that parameter was changed to `True` *and
deprecated* in 0.9).
However because DeprecationWarning was made silent by default in
Python 3.2 and the way the check is implemented worked for 0.9 it
looks like nobody really noticed it's broken in the usual manner of
half-assed version checks: works for 0.9.0, doesn't work for
0.12.3 (because lexically 0.12.3 < 0.9.0).
Fix by using proper version parsing and comparing the result of that.
See also: odoo/odoo#28116closesodoo/odoo#31553
Signed-off-by: "Xavier Morel (xmo)" <xmo@openerp.com>
The location_id and warehouse_id fields on product.template are just
dummy field intended to add something in the context that will be used
to compute the data being rendered (eg. for location, the quantity
displayed is the quantity of the product in the searched location).
But the feature was broken at a point, and has been solved in 11.0 with
7c7b099273.
This solution was not implemented in 10.0 up to saas-15 since this is
not acceptable for a stable version.
This changeset is only for 10.0 up to saas-15 to implement the fix
differently.
opw-1945417
closes#31475
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
Improve performance (*3) on _compute_product_availability
`mapped` makes use of orm prefetch, which is inefficient in this use
case when facing high volume.
closesodoo/odoo#30545
On some devices and chromium with printing option "Background graphics",
a printed receipt on the point of sale could have a black bottom below
the receipt content.
This is caused by the point of sale black background and happen rarely
because most frequently browser printing remove backgrounds.
opw-1940434
Co-authored-by: Romeo Fragomeli <rfr@odoo.com>
closes#31472
Before this commit, doing expression.OR() with only FALSE_LEAF would
yield [] which is equivalent to TRUE_LEAF and is therefore not correct.
The same happened (to a lesser extent) with expression.AND() within an
expression.OR(), since the former would return a [] which would be
ignored by expression.OR().
See tests for a clearer view of the use cases.
Fixes#30113, #26540closesodoo/odoo#31202
The admin can decide to publish/unpublish messages in the comments
of a product from the website. The button is also shown for notes
even if they are never published.
opw-1935337
closesodoo/odoo#31420
When importing an invoice without specifying the type, the invoice type
is set to `out_invoice`, but the account set is the supplier account.
At this point, the invoice type is simply undefined (`False`). It will
be set by default at creation to `out_invoice`. Therefore, we reach the
`else` condition which uses the supplier info.
We simply inverse the condition, so it creates a consistent object.
However, it raises a bigger question about how the action context should
be kept at invoice. We won't address it :-)
opw-1925547
closesodoo/odoo#30154closesodoo/odoo#31373
- Switch to French language
- Go to Inventory > Inventory Adjustment
- Launch an adjustment
The field 'Real Quantity' doesn't follow the float formatting.
This is because the widget is set as `field_float_scannable`, which is
not recognized by the formatting function.
Since the widget descriptor has priority over the type descriptor, we
must explicitly take this widget into account, on top of adding the
`format_value` method.
opw-1940884
closesodoo/odoo#31366
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
Lucas Perais (lpe)