Commit fcb972d skipped a test on saas-12.2 after forward port as it was not
working on that version.
This commit restore the test and fix it.
It was actually a race condition on the save step on edit mode.
Something similar was done already for another test, see 74a98ea.
closesodoo/odoo#31465
When a blocking message is configured on a product, we force the removal
of the `product_id` on the SO line. This causes a problem in method
`_get_display_price`. When the pricelist is configured with
`discount_policy != with_discount`, `get_product_price_rule` is called
with an empty `self.product_id`.
We move the `product_id` removal at the end of the onchange.
opw-1934386
closesodoo/odoo#31456
With the BS4 update, a traceback occured when clicking on a m2m tag using colors
in a list view.
When using colors on m2m tags, the badge was wrapped inside a `dropdown-toggle`.
However, there is no `dropdown-menu` by default (it is only rendered in FormFieldMany2ManyTags
when clicking on the `.dropdown-toggle`, hence the traceback.
The `dropdown-toggle` class is now only set if necessary.
Task 1925313
closesodoo/odoo#31445
- Activate 'Multiple prices per product'
- Create a Product A, and add an entry in the 'Pricing' section of the
product form
- Create a SO, a product, and add A in the 'Optional Products' tab.
- Click on 'Add to order lines'
A crash occurs at currency conversion.
When getting the conversion rate, the company is empty in method
`_get_conversion_rate`. This is because the company is a stored related
field, which is computed after creation. However, the method
`_prepare_add_missing_fields` is called before creation. This method
calls several onchange methods, one of them computing a price
conversion.
We explicitly add the company when creating the SO line.
opw-1939106
closesodoo/odoo#31455
- Create a product with variants
- Create a BOM for this product
- Add a component, specify a variant in 'Apply on Variant'
- Change the product of the BOM
The 'Apply on Variant' fields remain filled, although it doesn't apply
anymore to the new product.
opw-1943918
closesodoo/odoo#31435
In some special instance, a mention could get linked and the user would
not really be linked.
This is because of a difference between linking the mention and adding
the user as follower that required a space after the mention.
With this change:
- `[adding mention]@admin [backspace].`: was linked but not added as
follower => now it is not linked either.
- `[adding mention]@admin [backspace][enter][adding mention]@admin `:
the first @admin was linked => now the second is linked
Without the change, added test fails with:
"should not contain a link in the message content"
"should not have linked mention without space"
opw-1934946
closes#31433
The SSF would properly mark its own records as deleted, but it would
not properly handle deletion requests coming from an onchange, and it
would not necessarily convert DELETE_ALL commands (5) into the proper
sequence of individual (2)s matching existing records.
closesodoo/odoo#31431
Before this commit, we used dict keys before they existed
And made the share button crash
After this commit, there is no crash
OPW 1943301
closesodoo/odoo#31427
The margin-top/margin-bottom on a address on the top of the report does
not work because:
- display flex on an address in wkhtmltopdf is not perfectly implemented
and seems to remove vertical margin
- margin-top on the page first visible element is removed
To fix this issue, this code remove the display:flex on the address
widget and add an empty "visible" element at the start of pages.
opw-1925894
closes#31184
Before this commit, the template that was rendered when sending
an email to a customer to invite hime to pay online
was not translatable
This was because the override of the template did not have an xml_id
After this commit, it is translatable
OPW 1944258
closesodoo/odoo#31396
When the currency used for a payment/internal transfert is not the same
as the company currency, the prices shown in the reconciliation
suggestions are computed using the company currency.
1) Enable multi-currency.
2) Setup two bank, one in USD, the other in EUR.
3) Leave the company currency to USD.
4) Create an invoice for a partner targeting the EUR bank and
validate it.
5) Create a bank statement for the EUR bank amounting the **exact**
value of the invoice for the **same** partner and reconcile it,
this will create the payment behind the hood.
6) In the reconciliation the invoice appears as suggestion, if the
currency symbol is correct, the amount is shown as USD.
opw-1937202
closes#30623closesodoo/odoo#31290
Have an editable list that begins with a date/time field
create a line.
The first field is focused and the datetimepicker is popped up
Now, stroke ESC key
Before this commit, there was a traceback because the datetimepicker received an erroneous
BLUR/INPUT event
After this commit, there is no traceback as we detroy the widgets of the line
(including the datetimepicker) before removing the row from the DOM
OPW 1932409
closesodoo/odoo#31342
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#31330
Let users A, B be in in companies C1 and C2,
such that A is currently in C1 and B in C2.
User A tries to assign to B an activity on record R belonging to C1.
It fails because at the time of the check B is not in the correct company,
even if B could handle the activity after switching company.
The _check_access_assignation was added in commit 96a223a5f0,
to avoid activities to be created for records that the target user can't read.
Previous use-case is a legitimate one where we want to bypass this restriction.
Note that the systray notification widget is not company dependent,
and there is no way to remove a notification on a record the user can't read.*
In case where the record is company dependent and on a different company,
we skip the record rules check.
It is assumed that the check would fail because or company-related record rules.
It will create some unwanted activities, but only the minimal number we can let
through while allowing for all legitimate flows.
*Better solution for master is to give the user some more explicit message
if reading the record, suggesting to switch company,
or to allow to dismiss the notification altogether.
opw 1933862
closesodoo/odoo#30810
Have a SO; accepted and signed; and the client choose to pay with wire
transfer.
Before this commit, the transfer's transaction is never updated to 'done'.
Even after the invoice is created and the payment is encoded and
reconciled. The client will continue to see the pending message.
Now, when the SO is confirmed, the transfer's transaction is set to 'done'.
The client will see the done message.
opw-1935516
closesodoo/odoo#31352
Before this commit, it was impossible to search anything in the list view
when doing a Inventory Valuation > Current Inventory
After this commit, a few meaningful fields are searchable
OPW 1943676
closesodoo/odoo#31356
fix retro compatibilty
Old qweb template http_error_debug was wrong, but we never entry in the if.
Now that we fixed to enter in the if, we need to make retrocompatible code to
be able to display the QWebException from v9 with the old view from v8.
odoo.exceptions.QWebException
vs
odoo.addons.base.models.qweb.QWebException
closesodoo/odoo#31383
The issue happened when a user which does not have access to some fiscal
position try to print a sale order. In this case a traceback is generated.
In order to avoid the traceback and to be able to print the report
the access rights are bypass thanks to a sudo() in the report.
OPW-1943727
closesodoo/odoo#31357
Before this commit, the unit price in the invoice's reports, had the
same decimal precision as the currency and not the one specified for the
unit prices.
Now, the reports shows the unit prices with their specific decimal
precision.
opw-1940406
closesodoo/odoo#31314
This rev. fixes 3 issues with async (field) widgets in the kanban
view.
From rev. 5faec34a, widget'$el doesn't exist before start. This
means that for async widgets, one can't interact with the widget's
$el right after calling appentTo. In KanbanRecord, this is exactly
what we did for both field widgets (<field name=.../>) and widgets
(<widget name=.../>).
Moreover, when the kanban view was updated (e.g. when the user
refined the search using the search view), and the rendering was
async (because of the presence of an async widget), the renderer
didn't wait at all for the widget to be ready before updating the
view. This caused flickering, mostly, but also a crash in
accounting with the JournalDashboardGraph widget (because
on_attach_callabck was called before the widget was ready). To
reproduce this particular issue, go to accounting, add a filter
that doesn't match any record and save it as favorite (default),
press F5 (no record is displayed), remove the filter.
opw-1925079
opw-1925479
Fixes#30087Closes#31254closesodoo/odoo#31327
Go on the website, create a new product from there
Click on the image to change it, select an unsplash image
Save your product.
Beforer this commit, the image wasn't saved because the qweb field image
did not know what to do with /unsplash/ urls
After this commit, the image is saved on the product (or any object...)
OPW 1936191
closesodoo/odoo#31328
- Create a product category A
- Create a product category A1
- Add a product in A1
- Launch an inventory adjustment on A, and select 'Exhausted Products'
All products (even from other categories) are included.
Since there is no product found in the category `products_to_filter`
and `quant_products` are empty. Therefore, we fall back on
`[('id', 'not in', [])]`, which selects everything.
The root cause is that we don't include child categories. There is no
real point of doing so.
opw-1932192
closesodoo/odoo#31322
Currently tooltip goes out off the screen when the
graph view (in line mode) presents a large number
of groups.
The present commit splits the tooltip content in
three columns when the number of groups exceeds
20. This split is not done in mobile mode because
it is not an appropriate in that situation.
Co-authored-by: Mohammed Shekha <msh@openerp.com>
Related to Task: 1917958
closesodoo/odoo#30288
In graph line mode, min and max abs are
displayed beyond the screen when there are less
than 3 abs.
This is happening because nvd3 fixes their
text-anchor to 'middle'. The present commit fixes
correctly their text-anchors to start and end
respectively by using the '!important' rule (it
seems difficult to do otherwise).
Co-authored-by: Mohammed Shekha <msh@openerp.com>
Related to Task: 1917958
On the accounting dashboard, click on the button
"new invoice" on the customer journal.
Validate the invoice
Before this commit, it crashed because, as always
the key "default_type" was propagated all the way down
to the attachment creation
After this commit, we clean the context from that key
to avoid the problem
Note: There is no clean and safe method to clean
the context from keys only useful to `default_get`
in stable...
OPW 1943439
closesodoo/odoo#31319
In the user preference, change the timezone of the user to blank (False value)
Save
Before this commit, a cryptic error was raised because the field tz in
resource.resource is required
Note that when writing on res.user, we write some fields (including tz)
on hr.employee, which is a resource.mixin, and therefore uses resource.resource
After this commit, we make the field required in the view
OPW 1934462
closesodoo/odoo#31312
since the fix of the forward-port has missed checking the chart template
too
https://github.com/odoo/odoo/commit/2bba89c4ad5d393a15e02f0b7435ea7c63935bb0
Check the chart template is required because company could have a chart
template and any record at ['account.move.line', 'account.invoice',
'account.payment', 'account.bank.statement'] models
closesodoo/odoo#31218
Before this commit:
If a view A was doing a t-call on a view B and view B had view C as child.
And view A had view D as child.
And view D also t-call view B (that as mentionned above has view C as child).
And view D was inactive.
Then COWing C to set it as inactive would make `get_related_views()` on A to
return both generic active C and COW inactive C.
This rare case appeared for customize option that were enabled by default, like
wishlist, compare..
Disabling this customize option would show both the generic customize view and
the COW customize view.
Resulting in the customize toggle being shown twice, one enabled and one
disabled.
Detailed explanation:
1. `website_sale.products` would call `_views_get()` with `options=True` for its
t-call node `website_sale.products_item`, returning the full view tree,
including COW wishlist.
2. `website_sale.products` would then call `_views_get()` on its child views
with `options=extension.active`.
It is the case for `website_sale.products_list_view`, which also has a
t-call node `website_sale.products_item`.
It would then perform the same `views_get()` as in step 1. but with
`options` set to the view active state, in this case False.
At that point, the `_view_get_inherited_children` method would filter by
active before filter_duplicate, leaving the generic view over the specific
one as it should.
closesodoo/odoo#31286
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
Romain Derie