If a visitor tries to send a file too large, they will get a message after a
while that an error occurred. The message isn't specific enough.
With this commit:
- when a visitor sends a form, a spinner will appear indicating that the file
is being uploaded.
- if the upload fails because the file is too large, the user will be notified.
task-2234699
closesodoo/odoo#70301
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Co-authored-by: Romain Derie <rde@odoo.com>
Co-authored-by: Arthur Detroux <ard@odoo.com>
This commit makes it so boms are no longer required for a replenishment
of a product via the manfuacture route. This change is related to the
v14 refactoring of the manfacturing app to make it more flexible and
user-friendly. In the refactoring, manufacturing orders no longer
require a BoM, therefore a MO created by a replenishment should also no
longer require a BoM.
closesodoo/odoo#64910
Task: 2422698
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Prior to this commit, MOs would throw a usererror if there were no
components in it. This restriction made it so MOs created by a
replenishment (i.e. `warehouse.orderpoint`) for a BoM with no components
were never confirmed and the `qty_to_order` would accumulate for each
replenishment's new draft MO.
Steps to reproduce:
1. create a bom for a new product (w/ manufacturing route) with no
components
2. create and confirm a sales order for the new product
3. go to Replenishment and automate the product's replenishment
4. create a new sales order for the product
Expected result: 2 confirmed MOs where the quantity of the first MO
matches the first sale order's quantity and the 2nd MO matches the
second sale order's quantity
Actual result: 2 draft MOs where the first MO matches the quantity of
the first sale order and the second MO matches the quantity of the first
sale order + the quantity of the second sale order
This commit makes it so MOs can now be confirmed even when it has no
components. Note this requires changing the logic in a few locations to
ensure expected behavior still occurs including:
- backorders are automatically confirmed.
- `reservation_state` is recalculated when expected (will be blank when
no components).
Task: 2422698
To reproduce:
1. create and confirm a MO with register number checks on operations
2. duplicate the MO
The register number checks won't show up in the new MO
We didn't set copy=False for workorder_id on stock.move, when copy a
confirmed MO, the new moves are linked to old WOs on old MO. New WO
didn't link to any moves.
When create quality checks, we only create "register ..." checks for WOs
with move_id. As a result, new WOs without move_id won't have those
checks.
To fix, set copy=False on workorder_id of stock.move
Task 2484939
closesodoo/odoo#71000
X-original-commit: 6aaf337558e59474efcef937f0175ee531b4b477
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
before this commit:
_adapt_parent_account_group or _adapt_parent_account_group call with multi-company record then raise singleton error
after this commit:
singleton error is fixed
closesodoo/odoo#70977
X-original-commit: 40797b0705f3df210cbc7119944583addfc72684
Signed-off-by: William André (wan) <wan@odoo.com>
Issue
Use Safari (or equivalent) browser
- Install e-commerce
- Go to Website -> Configuration -> Payment Acquirers
- Activate Ingenico in test mode
(write aaa in required fields)
- Go to shop, and add product to card
- Go to checkout
- Select Ingenico payment mode
- Click on Pay button
- When on the ingenico page, press back
The page is blocked and the button is disabled.
Cause
When clicking on Pay button, the page is locked and
the button is disabled.
With Chrome, when coming back to previous page,
this one is regenerated and therefore adapt the button.
In Safari, it is not the case.
Solution
On `pageshow` event, if event have `persisted` attribute set to
to true, meaning using cache, then reload page.
Fixes https://github.com/odoo/odoo/issues/69453
opw-2510281
closesodoo/odoo#70906
X-original-commit: c89224940bcc59aab4bddefa95b2b0ef7713e02f
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
When there is a materialized view that has not been populated any select
on it will fail.
Example of traceback:
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/12.0/odoo/service/server.py", line 1162, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "/home/odoo/src/odoo/12.0/odoo/modules/registry.py", line 86, in new
odoo.modules.load_modules(registry._db, force_demo, status, update_module)
File "/home/odoo/src/odoo/12.0/odoo/modules/loading.py", line 367, in load_modules
registry.setup_models(cr)
File "/home/odoo/src/odoo/12.0/odoo/modules/registry.py", line 262, in setup_models
env['ir.model']._add_manual_models()
File "/home/odoo/src/odoo/12.0/odoo/addons/base/models/ir_model.py", line 321, in _add_manual_models
cr.execute('SELECT * FROM %s LIMIT 0' % Model._table)
File "/home/odoo/src/odoo/12.0/odoo/sql_db.py", line 148, in wrapper
return f(self, *args, **kwargs)
File "/home/odoo/src/odoo/12.0/odoo/sql_db.py", line 225, in execute
res = self._obj.execute(query, params)
psycopg2.errors.ObjectNotInPrerequisiteState: materialized view "x_bi_sql_view_report_copy" has not been populated
HINT: Use the REFRESH MATERIALIZED VIEW command.
```
Several upgrade requests have or had had this error which has been
solved with specific scripts.
Related to #40930closesodoo/odoo#71008
X-original-commit: b208570ce8399bc6d3e4a8ba02eef6558e0a6ccc
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Currently, the selection field and boolean field values are displays
below the string 'search for: '
like, Search status for: input value
New
Running
Cancelled
so, this commit improves the quick search dropdown by displaying the
selection field and boolean field value and strings in the same line
like, Search Status: New
Search Status: Running
Search Status: Cancelled
TaskID-2462138
closesodoo/odoo#67575
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
data-parent fields were set on tab link and not on the tabpanel
div. It prevented the accordion of having the right behavior:
closing all the other tabs when a tab is clicked to be opened.
closesodoo/odoo#71001
X-original-commit: 51c868bd9bfcd9a7e81f386b0c889befa5dd6e20
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Signed-off-by: Sébastien Mottet <smottet@users.noreply.github.com>
Purpose
=======
We want to be able to force the FROM headers when we sent email in
SMTP. So we can avoid the emails to be considered as spam.
Specifications
==============
This is done with 2 system parameters.
If the system parameter `mail.force.smtp.from` is set we encapsulate all
outgoing email from with the given value.
If the previous system parameter is not set and if both
`mail.dynamic.smtp.from` and `mail.catchall.domain` are set, we
encapsulate the FROM only if the domain of the email is not the same as
the domain of the catchall parameter.
Otherwise we do not encapsulate the email (same behavior as before this
commit).
Task 2367946
See odoo/odoo/pull/61853
closesodoo/odoo#70980
X-original-commit: 08a561505b92d23c4c4ec4094b0cee209ece8753
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
If 'send by post' is enabled and the address is incomplete when we send one invoice, display:
"The customer's address is incomplete:" followed by a link to the corresponding partner
If 'send by post' is enabled and some addresses are incomplete when we send invoices in batch, display:
"Some customer addresses are incomplete. [number of incompete addresses] Contacts"
and if we click the Contacts, we will be redirected to the corresponding Contacts
Purpose:
When the user tries to send an invoice by post, the system warns him that the customer's address is incomplete.
But then, it's a dead end. The user doesn't have any tool to rectify the situation.
closesodoo/odoo#69469
Taskid: 2502597
Related: odoo/upgrade#2445
Signed-off-by: Arnaud Joset <arj-odoo@users.noreply.github.com>
You can, in a production order, change the quantity done of a stock move
raw and change its initial demand ('To Consume' field) in the same
transaction. This can lead to some issue as changing the quantity done
will update the stock move line and changing the initial demand will
unreserve the stock move thus impacting the stock move lines too.
This commit will split the values to update of a stock in move in case
the two fields have to be updated. First the stock move lines, then the
initial demand.
This commit also remove the default_product_uom_qty in the move_raw_ids
fields. This ensure the onchanges do not create/edit any stock move lines
with some reserved quantity.
opw : 2451298
closesodoo/odoo#70975
X-original-commit: e8c1f6b1a3f58b68181bf4d2599bd37efb83b5c7
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
website_forum.faq_accordion is not rendered by a drag'n'drop
and data-parent is therefore not set on tabpanels by onBuilt.
closesodoo/odoo#70978
X-original-commit: d4e046209914a7be3aed976a1fc3a74020843309
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
accordions in pages created by configurator have not been
added by a drag'n'drop. onBuilt is therefore not called and
attributes (data-parent and id for tabpanel and data-target
for tab) are not set. We set these attributes directly
in the xml to make accordions work also for configurator.
closesodoo/odoo#70974
X-original-commit: 887f6d539ebf4f3a6d95f44f2cdd4152b59d5910
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
As pickings can be moved from a batch into an another one, a batch can suddenly
be emptied or having no more active pickings.In such case, we cancel it.
This way, empty batches won't be displayed by default as there is a default
filter showing only draft or in progress batches.
If we manually remove all pickings from a batch or create a empty batch, we
consider it intentional, and won't cancel it automatically.
Task-2464457
PR #66600
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
batch
We already allowed the stock.picking.to.batch wizard to create batch
with pickings already in other batches. This commit will also allow you
select pickings that are already in other batches on the batch form.
Task-2464457
PR #66600
This commit update owl to the latest release. It only contains a small
fix on the order of lookup for the t-component directive.
Release on github: https://github.com/odoo/owl/releases/tag/v1.2.5closesodoo/odoo#70972
X-original-commit: 67e706b76fefa7eaff12722a4bda6fa4ce497eaf
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When the user removes the readonly from the field date order and tries
to modify it it crashes in some cases, this commit fix this
opw-2523508
closesodoo/odoo#70969
X-original-commit: 3e4a541277828ec9cd0bd97587c6d87dc91ccf08
Signed-off-by: Achraf <abz-odoo@users.noreply.github.com>
The account payment file being quite big already,
and the payment methods being modified in another
task (2414749) we'll extract them into their own
file to make it easier to work with them
closesodoo/odoo#70937
Related: odoo/enterprise#18367
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Before this commit, evaluating a domain containing a like/ilike
operator with an evaluation context in which the value was false
crashed.
Moreover, those operators were wrong w.r.t. the case sensitivity:
like was case insensitive, whereas ilike was case sensitive, and
both =like and =ilike were case insensitive.
This commit fixes thoses issues.
The first issue was spotted on our prod, as we tried to add an
invisible attrs in a form view, using the ilike operator (it thus
crashed in create mode).
The second issue was spotted while writting the test cases.
To the best of our knowledge, those operators aren't used in attrs
(for now), explaining why those issues haven't been found before.
closesodoo/odoo#70951
X-original-commit: 44e185dbd6ddeda7cdcd76882fa0bd231e9d3f37
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Creating an account move from a valuation layer is bypassed in
case the product is consumable. Since 7fa9ec2638, the signature
of _account_entry_move() changed. It no longer return an account move
but a list of values to create everything in batch.
Testing the product type should now return `[]` instead of `False` in
order to be added to the existing list.
closesodoo/odoo#70945
X-original-commit: 5d76ce38a8551f430449b997a875ccc3b5a728cb
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
When starting work on a blank website, it was possible to start writing
text in the blank page. However that was never the purpose and things
behaved improperly from there.
This commit addresses that problem by consistently applying
contenteditable=false to the #wrap element when it is empty, and true
when it isn't.
At the same time it fixes the fact that starting with a non-empty page
and making it empty failed to show the empty editor message.
closesodoo/odoo#70933
X-original-commit: c9ab6ae3e1e1859c36a4f6e68a7cae25cf92a7b3
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
When changing the number of columns of a snippet, the history was
recorded too many times and at wrong moments, resulting in a mess of
undos to trigger before restoring the original column state.
The issue was due a combination of dead code and the fact that
`_updateColumnCount` triggered `remove_snippet` for each of its columns
while `remove_snippet` in turn triggered a history step at every
execution.
This fixes it by removing the dead code, replacing it where necessary
with a call to the editor's `historyStep` method, and adding an option
to `remove_snippet` so its triggering of a history step can be bypassed.
closesodoo/odoo#70932
X-original-commit: 877e5c807087afed880aeba3eab79def3a7b583c
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Since the link tools were moved from the modal to the sidebar, the url
autocomplete dropdown stretched out of the bounds of the window.
This fixes that problem while restyling the dropdown to look like the
url pickers we already have in the sidebar. In order to achieve that,
we apply to it the "o_website_ui_autocomplete", used by
UrlPickerUserValueWidget (to which we don't have access in the toolbar).
closesodoo/odoo#70931
X-original-commit: 704583aad98287adac9e13772cfb8ca0933b0a32
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
When selecting the contents of a promo code then typing a letter, that
letter was inserted before the promo code instead of in it. It was also
impossible to get back inside the promo code after that.
Given the nature of that snippet it seems reasonable to make the promo
code itself unremovable. This way we can benefit from the editor's
ability to keep the cursor in an empty unremovable inline.
Note: This fix requires a change in the editor:
https://github.com/odoo-dev/odoo-editor/commit/1c98f141458de297a4b819f3fb21f532986e9872.
Do not merge without it.
closesodoo/odoo#70930
X-original-commit: ffe0277613f73e046c4e343cfb0197c937063717
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Following the recent reorganisation of the documentation in 12.0+,
the majority of the documents have been moved and their old links are no longer valid.
Some redirection rules will soon be deployed, but those rules might be dropped in some years
and we want the links to still work, which is why we still replace the links to the new ones.
FW-Port of odoo/odoo#70675 (13.0)
closesodoo/odoo#70920
X-original-commit: bc9c1eef538ba6095e74c19d5d9ed9e01625ec7c
Related: odoo/enterprise#18361
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
When building a domain `(=|!=)` with
a Binary field stored in attachment and
the right part of the domain is not null,
the full binary content is logged, giving
the logs a huge size.
Now, the content of the binary is cropped to
20 chars as it is useless to log more.
opw-2527629
closesodoo/odoo#70740
X-original-commit: 0ed46ae94b20b30c10025b2a458e1ecf92c2712d
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Before 03025520b rounding applied was eg. for these numbers and UP and
DOWN rounding methods to multiple of 10:
```
Numbers | -8 | -2 | 2 | 8 | 12
DOWN | -2 | -8 | -2 | -8 | -2
UP | 8 | 2 | 8 | 2 | 8
```
which is correct for positive numbers but UP and DOWN are inversed for
negatives numbers.
After 03025520b this became:
```
Numbers | -8 | -2 | 2 | 8 | 12
DOWN | 8 | 2 | 8 | -8 | -2
UP | -2 | -8 | -2 | 2 | 8
```
which is correct for all cases except for positive numbers that are
before HALF of the precision (eg. number 2) for which UP and DOWN are
inversed.
This is happening because 03025520b uses the sign of the rounded value
=> this does not work for 0 so number 2 is broken (and if fixed number
-2 would be broken).
With this commit, the adjustement of sign is done based on original
number, so we get the equivalent of python equivalent methods:
```
Numbers | -8 | -2 | 2 | 8 | 12
DOWN | 8 | 2 | -2 | -8 | -2
UP | -2 | -8 | 8 | 2 | 8
```
opw-2451841
closesodoo/odoo#70923
X-original-commit: 23dd2ea535bea0a57dcac773a81e202135cd2ed6
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
The "Starting job X" and "Job X done" logs are very useful to monitor
cron executions over time, or to detect a cron job that has been running
for a long time.
Those logs were dropped by mistake in #62124 - this patch restores them.
closesodoo/odoo#70921
X-original-commit: 0db99a9fb00465266485c7f6c8d16760250152df
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Steps to reproduce the bug:
- Go to Project app
- See the overview of any project
- Select at the top right another company with a different currency. But keep the company assigned to the current project selected
Problem:
The new currency is changed in the project overview, but the values are not converted to this currency.
opw-2479364
closesodoo/odoo#70902
X-original-commit: 7f9cacd40d185bb7c943bd2adb7de1ef8a39c367
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Djamel Touati <DjamelTouati@users.noreply.github.com>
Before this commit, status codes were partially handled and users may not had a proper feedback on the status of their payment.
Task #2517498closesodoo/odoo#69948
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Currently, the default invoicing policy is based in `delivered`
quantity since commit: https://github.com/odoo/odoo/commit/3ad4abe171e8e7e86ed0e7b7f000e734d8a2ad92
but due to that onboarding flow is often broken/very complex.
hopefully the statement 'in countries with anglosaxon accounting, that's mandatory' is exagerated.
So in this commit, Default invoice policy is set (back) to
'Ordered quantity'
closesodoo/odoo#69825
Taskid: 2443371
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Before this commit, some requests could be sent to the actual IAP
servers during testing. These calls weren't always mocked as many
of these requests are sent in background while performing usual
tasks such as creating a bill.
Now, any call to the function iap_jsonrpc during testing will result
in an AccessError.
closesodoo/odoo#70925
X-original-commit: f31f1972ff0e35deb3005ce160930b70ddc8e531
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
This reverts commit d89562e8fe473692296cb209651beb2ce7a715e4.
Since this commit, the taxes mapped by fiscal position wasn't managed by the _fix_tax_included_price_company method anymore.
Otherwise, some customizations exist on this method that are no longer called.
The 2527940 issue is also due to a remaining bug: the total_excluded price should be divided by the quantity but:
- what if the quantity & price_unit are both signed?
- what if the number of digits for price_unit and the currency are different? Should we skip the rounding of taxes?
Since this commit is not perfect and has a lot of dependencies in others modules, we decided to revert it.
Original PR: https://github.com/odoo/odoo/pull/68997
Revert PR: https://github.com/odoo/odoo/pull/70858closesodoo/odoo#70914
Issue: 2527940
X-original-commit: def7d7bb0231fef38e044803b245c9b990a90216
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Before this commit, when the user edits the description of a task with
use_pad=True and then change the project of this task to one with
use_pads=False. The description written in the pad server is not copied
in the description field of the task.
This commit copies the content of the pad for this case when the use_pad
changes to become False and description_pad is set.
Step to reproduce:
-----------------
1. Go to Settings of the Project App and enable the Collaborative Pads
2. Go to the Project App, in the Projects dashboard (kanban view of projects)
3. Create two Projects (one called "Project A" and the other called "Project B")
4. Edit the Project B to activate the pad, that is, check the Use
collaborative pads checkbox.
5. Go to the view list of tasks in the "Project B"
6. Click on "Create" button to create a task in the task form view.
7. Write a description for this task.
8. Change the project of this task by the "Project A". With this change,
the collaborative pad is disabled for this task since the Project A has
not the pad, and then the description field is empty rather than have
the content that we have just written.
task-2515150
closes#70401closesodoo/odoo#70917
X-original-commit: 32a8f598d6a958f2a08b204524007cc075697fda
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
Before this commit, in Project App, when the "Collaborative Pads" is
enabled in the Settings of this app, if the user create a task without
project or in a project that has not the pad enabled and he writes a
description for his new task and select (another) project in which the
pads is enabled then the description field in the form view changed to
have the collaborative pad and the problem is the description is not
copied in the pad and seems erase/delete for the user.
This commit checks if the pad_content_field is not empty after
generating the pad url for the new task/record, if it is the case then
we copy the content in the pad and the user can continue his edition
before saving the task/record.
Step to reproduce:
-----------------
1. Go to Settings of the Project App and enable the Collaborative Pads
2. Go to the Project App, in the Projects dashboard (kanban view of projects)
3. Create two Projects (one called "Project A" and the other called "Project B")
4. Edit the Project B to activate the pad, that is, check the Use
collaborative pads checkbox.
5. Go to the view list of tasks in the "Project A"
6. Click on "Create" button to create a task in the task form view.
7. Write a description for this task.
8. Change the project of this task by the Project B. With this change,
the collaborative pad is actived for this task since the Project B has
the pad, and then the description in the pad is empty rather than have
the content that we have just written.
task-2515150
closes#70401
X-original-commit: d2b55c775d705128fa65c859c5f47bdaf4b705fe
- fix missing access rights when handling feedback data
- redirect customers to the payment confirmation page when notification
data are not acknowledged by PayPal, rather than displaying an
internal server error
task-2494916
closesodoo/odoo#70885
X-original-commit: 948c22243c88dd905f1a7838f6fba75f44f06b2a
Related: odoo/enterprise#18349
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
In Ogone's backend, it is possible to remove `CARD.CARDNUMBER` from
Flexcheckout's feedback data (Configuration -> Technical information ->
Transaction feedback -> Alias gateway and Tokenization -> Dynamic
parameters). Since this is the configuration that was suggested to Odoo
customers migrating from a previous version, we must be able to process
feedback data when the card number is missing.
This commit creates an anonymous card number ('XXXX...') if one is not
provided by Ogone.
task-2494916
closesodoo/odoo#70896
X-original-commit: 272c4259624d88e2d061c6418109d4e0c2dbfb2d
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
Issue
- Install "Contacts" & 'base_address_extended' modules
- Go to contacts and create a contact with value:
- street name : Chaussee de Namur
- House : 40
- Save and edit again
- Set country to 'Netherlands' then save.
Address not splited well (wrong values for street name and house).
The issue is not present in UI but is in tests.
(Issue in UI from odoo 14.0+)
Cause
There is 2 '_split_street_with_params'
(inverse function that set street fields):
- partner_autocomplete_address_extended (removed in 14.0)
- base_address_extended
The 'spliting' logic is not the same in both function.
In UI, looks like it does not call '_split_street_with_params'
from 'base_address_extended' since no super(Partner, self)...
However in testing, it does call it from module
'base_address_extended' and therefore trigger the issue.
Solution
Adapt _split_street_with_params function
(in 'base_address_extended' module):
If previous field (from 'street_format') to parse
in 'street_raw' is 'street_name', then:
- set `tmp` to: splitted (max 1 split) street_raw
with current field seperator
- set `append_previous, sep, tmp[0]` to:
splitted tmp[0] (first part of splited street_raw) with `rpartition(' ')`
- add 'append_previous' to 'street_name' value
- join 'tmp' values and set it to street
(should equal to what left from `rpartition(' ')` split
+ seconf part of first normal split)
- continue normal parsing flow
opw-2476096
closesodoo/odoo#70886
X-original-commit: 74116c982a5ddef65a05ef90017ac4ce63bdf58f
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
When partner is not selected, Odoo sends name_search request
`[..., ('partner_id', 'child_of', [False])]`. It's not obvious what does such
domain mean ( see #70584 ). This commit clarifies what do we expect to get:
we want all records without restrictions on `partner_id` value.
This also fixes performance issue because domain leaf `('partner_id',
'child_of', [False])` is converted to where-clause `<table>.partner_id in <all
or almost all ids>`
---
opw-2524010
closesodoo/odoo#70873
X-original-commit: 39e0f1fb0f60f309be7f65562911b1236167dce7
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>
When clicking on "CRM -> Reporting-> Leads (Leads Analysis)" list and form
views are not correctly set, leading to opportunity views. In this commit we
* have changed the list view from ``crm_case_tree_view_oppor`` to
``crm_case_tree_view_leads`` to ensure we use the right view;
* we are now able to open form view from the list view like all other views;
When clicking on "Teams -> Reporting (on a team vignette) -> Leads" list
view used is the opportunity one. We fix it by correctly setting action
views for ``action_report_crm_lead_salesteam`` reporting action.
Task-id : 2497936
closesodoo/odoo#69575
Related: odoo/enterprise#18338
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The FieldChar and the "Emoji" fields support a "onchange_on_keydown" attribute
that allow triggering the onchange event when the user types into the field.
(Instead of having to wait for a blur event).
This is especially useful, for example, in the social module to refresh the
post preview when the user is typing his message.
The current strategy to avoid spamming this onchange event was to throttle the
method to trigger it at most once every second.
However, triggering it every second could still be problematic in terms of
performances and could cause loading issues (e.g: if you have a large GIF in
your post preview)
To try to mitigate this issue, we changed the strategy from throttle to
debounce and changed the delay to two seconds.
Meaning the onchange will be triggered 2 seconds after the user is done typing,
which still gives a nice "live update" effect without triggering the onchange
too much.
Task-2500821
closesodoo/odoo#69023
Related: odoo/enterprise#17573
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
