When creating a new customer, the selection list for the state is empty
unless the country is filled in.
This is an issue since users usually fill the address fields in the
sequential order: street, city, state, zip and then country. Since no
state proposal is displayed, users tend to create a new state.
Introduced in 5fcf891e07.
opw-1941579
closesodoo/odoo#31273
When a picking is linked to a sale order, it is not displayed anymore
ont the user portal.
This comes from a fix in rev: https://github.com/odoo/odoo/commit/7825d008279702b3a5017196aa0345a0e48810c9
that hides the shipping_adress div, which is the one targeted by the
xpath for shoing picking. To fix this behavior, we changed the xpath.
TASK-ID: 1939813
closesodoo/odoo#31267
On the quote builder, we have a description per product that is either:
- the description of the product on the quotation template
- the quote_description of the product
and if it is empty we can edit it on the quote builder.
But if we have several of them, we only see several empty editing blocks
without knowing which product it refers to: thus if we removed the line
it could have adverse effects by removing something not related.
With this change, there is an alert when editing that explain each
line description being.
opw-1943009
closes#31263
To edit a view on the website, we use the branding mechanism.
This mechanism adds informations to node which can be edited about how
or where the change should be saved, for example:
```
<template id="a">
<div><b>hello</b></div>
</template>
```
might be rendered to someone that can edit it:
`<div data-oe-model="ir.ui.view" data-oe-id="5" data-oe-field="arch"
data-oe-xpath="/div[1]"><b>hello</b></div>`
when something is changed: we will send the modified content, the view
id (eg. 5 for view `a`) and the xpath in this view of what is replaced.
If a view is overridden, there is mechanism to distribute the branding
to children, for example:
```
<template id="b">
<div>
<b>hello</b>
<div>
</template>
<template inherit_id="b">
<div position="inside">
<b>world</b>
</div>
</template>
```
The branding can't be on the parent div that will contain other content,
because the other content is in another template and should not be saved
in template `b`, so this would be rendered like this:
`<div><b data-oe-model="ir.ui.view" data-oe-id="6" data-oe-field="arch"
data-oe-xpath="/div[1]/b[1]">hello</b><b data-oe-model="ir.ui.view"
data-oe-id="7" data-oe-field="arch" data-oe-xpath="/div[1]/b[1]"><b>
world</b></div>`
This changeset fixes two issues:
- if we have a primary inheriting view: the xpath are wrong in the
primary inheriting view part, they are computed on the view applied on
its inherit_id; the part of the inherit_id view have the primary
inheriting view ID instead of inherit_id view id.
- if we have `<div t-call="..."/>` in a view, the branding of view
should be distributed to children and not affect t-call part: this was
done for `<t t-call="..."/>` but not for `<anyothertag t-call/>`.
The added test failed on all assertions before the change:
- "test_branding_primary_inherit" would not distributed
- "test_call_no_branding" would distribute branding on `t-call`
opw-1937757
closes#31039
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
The Actions/Print dropdowns may overflow the screen in case of very long
lists of menu entries, when based solely on the default BS4 styles for
`dropdown-menu`.
The `o_dropdown_menu` class forces a vertical limit and a scrollbar when
this happens, and should be applied to those control-panel dropdowns to
prevent this UI glitch.
See also 1c1c0897e8 which adapted
dropdowns to BS4.
closesodoo/odoo#31251
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
The `company` context is explicitly set by `action_send` while the
template previewer doesn't set it. This inconsistency leads to
error when previewing the digest template.
opw-1939007
closesodoo/odoo#31195
_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
When duplicating a project, every task linked to the project is
duplicated too but the link between sub-tasks and their parent
task is not updated thus they are left linked to the task of
the original project.
opw-1937371
closesodoo/odoo#31154
When duplicating a journal, the alias is kept. Therefore, when the user
tries to change it, it updates the value on both records.
opw-1941717
closesodoo/odoo#31242
If the stage breadcrumb on the portal view is too long, it could get on
two lines but since they are righ-aligned in inversed order, the second
line (or more) will be the first stages.
With this fix, the breadcrumbs are left-aligned so on two line the
second line are the last breadcrumbs.
Also there was possibly a different order than backend since the order
is on "sequence, name, id" in backend but was just "sequence" here.
opw-1934497
closes#31237
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#30357
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
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
When an inline editor is eg. in a form view, the focus is always stolen
by it.
This is because we trigger a mouseup on the editor to update its
toolbars values and informations.
note: backport of 11.0's 7a453b0b7a
In 10.0 this trigger could cause a "blur" which in some instance is not
wanted (eg. inside a newline of a list view).
opw-1906581
closes#31078
The html widget automatically replace an empty field value by
`<p><br></p>` to be able to add content.
But this may cause unintended "onchange", since the value has "changed"
and the onchange themself could cause error when triggered at the wrong
time (eg. inside a list view with required fields).
With this changeset, the onchange is averted when the value was false
and is now `<p><br></p>`.
opw-1906581
closes#31078
Revert commit 296c5a2106
which was half-right: the accounting logic is correct but it overlooked
that it broke the reconciliation of cash returns
i.e. the client gives more money, and you return the change
Given that this latter use case may occur more frequently we focus on that
while we break freight returns
i.e. the client returns a product, and you give the money back
It is not possible to support both use cases because
ultimately we don't know from which order an account.move.line comes
the related PR #23356 should support both use cases
but adds a field on account.move.line
OPW 1925607
closesodoo/odoo#31037
This commits adds a message to the module import wizard to make it more
clear what kind of modules can be imported through the front end.
project : RD feedback
task : [base_import_module] what it is not for.
opw-1939967
closesodoo/odoo#31057
Calling `search` on `product.product` without specifying an order
will sort the products by name.
As the product name is a translatable field,
it requires to make a join on the translation table to sort
the product by their translated name.
This join is costly, and in this case it was completely
irelevant to do it, as the goal was simply to compute
a domain with only a list of product ids, for which
the order simply did not matter.
By forcing the order on the id,
we avoid the sort on the product name,
and therefore the join on the translation.
The performance is therefore improved.
opw-1930010
closesodoo/odoo#31066
- Set your company to USD
- Create an expense in EUR:
Amount: 100
Tax: 15% Excluded
- Validate, post the journal entries
It crashes because of a missing `.id`, but on top of that... not a
single AML is correct.
opw-1938570
closesodoo/odoo#30987
Force the location and destination location's company to match with the
picking and picking type company. This is to prevent users to move
products between companies without using a transit location, since stock
valuation is not supported.
The record rule `stock_location_comp_rule` gives access to children
companies. The domain added in the view is more restrictive, and allows,
for a company A, transfers from locations:
Company A -> Company A
Company A -> No Company
No Company -> Company A
opw-1893276
closesodoo/odoo#30952
- For 'res.config.setting' view, when there is a field with
'many2many_tags' widget, a drop-down is not displayed
properly. (For example, see 'default_cashbox_lines_ids'
field from point_of_sale module)
- This commit fixes the above visual glitch by properly displaying
the field having 'many2many_tags' widget on settings view.
Task id - 1935608
closesodoo/odoo#30956
The date picker should be displayed when clicking on the fa-calendar
when creating a note from activity systray.
The test was missing the assertion checking that the date picker was displayed,
but fixing this issue breaks the test. The datepicker looks to be
asynchronously initialized, and the blur event raises an error because of
that. Since it is difficult to test external libs behaviour, this
step is simply removed from the test.
Task: 1942850
closesodoo/odoo#31241
This fix prevents the chatter and attachment box
from assuming that there is a mail_thread on the record;
Reason: if a chatter is set on a record that doesn't inherit
mail_thread, the attachment box will generate errors.
closesodoo/odoo#31206
With Italian localization, the length of zip must be 5 for Italian buyer.
If the buyer is not Italian, we doesn't check his zip length.
closesodoo/odoo#31205
Some elements in the eCommerce are styled using the 'border_primary'
class. The color used by the class is however the wrong one, as it was
set to the odoo purple while it was meant to be the theme primary color.
This commit fixes the color.
Note that BS4 has an equivalent for that class (.border.border-primary)
but as this is a stable fix, it was not changed. It will be adapted in
master with https://github.com/odoo/odoo/pull/31147closesodoo/odoo#31214
- Set a barcode for a product A
- Open the POS interface
- Click on a product B => it is added to the order
- Scan product A
Product A is added to the order, but a unit of B is also added.
Commit 9de1bc0eef introduced keyboard shortcuts in the POS
interface. In particular, when a product is selected, pressing the SPACE
or the ENTER key adds it in the order. Since the barcode scanner sends
an ENTER key as a final character, it triggers the addition of both
products.
opw-1934520
closesodoo/odoo#31185
Christophe Simonis