The value provided by the sale quotation builder feature is small due to many problems, and the
technical debt behind is high. For instance:
- The feature is nice but hidden: not visible on quotation, the most visible part is the button
"Design Template" on the quotation template (if you did activate the feature), it requires to have
eCommerce installed...
- The feature relies on fields that are shared with eCommerce which leads to unwanted behavior:
e.g. updating the bottom of the product page in eCommerce will impact quotation html description on
the portal
- The feature works as template but it is unclear for users: updating the HTML description on a
specific quotation will only impact that quotation. Updating the HTML page of a quotation only
update this quotation
- The feature is technically complex
As we want to keep most of the value of the feature but reduce its complexity, we remove the
quotation builder feature that'll get replace with the PDF quote builder feature.
task-3249142
Part-of: odoo/odoo#133773
Co-authored-by: Victor Feyens <vfe@odoo.com>
Co-authored-by: Morgane Demesmaeker <edm@odoo.com>
*: board, website
This commit simplifies the UX of the 'Custom Group by' menu. Before this
commit, many clicks were needed to apply another filter, from an accordion
menu.
Now, a select element is used instead, allowing a better user experience, by
enabling such group by directly, when an option is selected.
Some tests have been adapted to the new selectors and behaviors, and the
applyGroup and toggleAddCustomGroup has been removed, since groups are applied
when selected, and the value can be modified directly with selectGroup.
task-3458519
closesodoo/odoo#132006
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
PURPOSE
Slightly modify various apps to improve the user experience. Changes include
notably labels and views fine tuning, roundings, and small css fixes.
SPECIFICATIONS
- Remove the decorator from the event list view as it's a bit confusing
- Ensure mailing KPIs are now shown with 2 decimal places
- Re-order the mailing stat buttons
- Improve the background / font colors of the cover block
- Improve the labels of:
- Title and confirm button of the /button and /link modals
- Confirm button when archiving a record
Task-3204554
closesodoo/odoo#128108
Related: odoo/enterprise#43937
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
users who create products from the website are intended to make it visible immediately for customers
task-3234684
closesodoo/odoo#117884
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Currently, in the survey for single/multiple choice questions, the layout is
not consistent. For example, if there are four choices available, the
layout is 3-1 (3 small options in the first row, 1 full-width option in the last
row). Apart from that, if the string for options is long, the radio/check
box comes at the bottom right corner, which should always be at the
top right corner.
This commit does the following improvements:
1/ Improve the choices layout to make it beautiful. now there will be only one
answer per row similar to the 'One Page Per Question' layout.
2/ The radio / check-box icon will be displayed in the top right corner
regardless of the length of the option strings.
3/ If there is one or more image(s) in the answers then we will follow 2x2
layout instead of one row per answer.
TaskID-2712296
closesodoo/odoo#99229
Signed-off-by: Florian Charlier (flch) <flch@odoo.com>
Before this commit, when we set the activity type to 'todo' in our project, the
default action was set to 'none.' This configuration made the 'todo' category
type less intuitive and less useful.
In this commit, we have improved the default behavior. Now, when you select the
'todo' category type, it will automatically have the 'reminder' action assigned
by default. This change enhances user experience and ensures that 'todo' items
have a meaningful default action.
task-3500700
closesodoo/odoo#135767
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
When the user tries to find the 'qty_available' of a product but gives
a string value instead of a float value in domain then the user will face error.
Steps to produce:
- Install `stocks`.
- Create a record rule for model `product.template`. In the domain of record
rule keep [('qty_available', '<', '10')] as a domain,
you can give any integral value in the domain but that value should be
enterred as strings (with quotes).
- Inventory > Products > Products
Error: `TypeError: '<' not supported between instances of 'str' and 'float' `
After applying our commit, if the domain is Invalid then the user will face
`UserError`. There is a function named `_search_product_quantity` which
initially checks if the domain is valid or not :
https://github.com/odoo/odoo/blob/5f1ad0c1e4c1e8ed41337ccd4c12e70c9c760c85/addons/stock/models/product.py#L342-L350
It will filter out all the invalid domain and clear search methods.
So now whenever `_search_qty_available` is called first the validity of domain
and operands of the expression will be checked.
sentry-4399815131
closesodoo/odoo#137367
X-original-commit: 92c232cca15517bd9a33a5100e7cdc42c3c25397
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
The text should be update, since we do not review applications anymore.
Also, currently if a user types a random text in the settings' search bar,
Peppol setting appears. Peppol settings should be enclosed in `block` tags as all other settings.
task-3525510
closesodoo/odoo#137355
X-original-commit: 156b0c94c2c9cf26b1168864c723e2ad2d720311
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>
The `partner_gid` key isn't part of the response of the Autocomplete API
of Clearbit anymore, so we can't rely on its presence to know if the
suggestion comes from Clearbit or not.
Ticket #3321391closesodoo/odoo#137354
X-original-commit: 63b8aa6b69d917c5c1cc83e11c530cd2fd665f25
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Signed-off-by: Louis Baudoux (lba) <lba@odoo.com>
We made it depend on the partner country, but it is better to
identify it through the tax being used. E.g. it is only the
exportation of goods that is needed to change the regimen
and not the services.
We also needed to change the test, because we used E2 with
a Belgian partner.
opw-3514270
closesodoo/odoo#137184
X-original-commit: 14d5be171e238d7aa12f513659929b5b940eea78
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Josse Colpaert <jco@odoo.com>
We use the casilla 10 and 11 of the modelo 303 to identify intra-community
instead.
This way, the tax defines the regime that should be used.
opw-3514270
X-original-commit: eb287e911afc652c122b44c39af4b6d6b11bf618
Part-of: odoo/odoo#137184
This commit brings a simple improvement.
There is no need to reposition an element while
you are scrolling inside of it.
closesodoo/odoo#137139
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
**Before this commit**
The tour_service make use of a custom
main component TourPointerContainer.
But there is really no good reason it does.
**After this commit**
The tour_service now make use of the overlay service.
Advangates:
- same place in DOM for all piece of UI that overlays
the other elements.
- should avoid potential stacking context issues
- removal of a useless component, less code to maintain
Part-of: odoo/odoo#137139
Previously, attributes had to be selected one by one on different pages.
For each choice, you had to click on the next button.
Now, all product attributes are on the same page, simplifying selection.
closesodoo/odoo#137107
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
This commit adapts the hover style of the editable fields elements to
match the new overlay style.
task-3368793
closesodoo/odoo#132653
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Prior to this commit, the first drop zone at the top and the last one at
the bottom were half hidden.
This commit adapts their position in order to be fully visible.
task-3368793
Part-of: odoo/odoo#132653
Prior to this commit, the area of top and bottom handles overlapped the
content according to the size of the overlay border.
This commit changes the way height is calculated to remove this overlap.
task-3368793
Part-of: odoo/odoo#132653
This commit adapts the draggable icon in the overlay button to improve
the readability.
This commit also adapts the "danger" background color of
`oe_snippet_remove` button to maintain consistency with the web editor.
task-3368793
Part-of: odoo/odoo#132653
improve the flow of invoicing tour by:
- moving some bubble to a more clear position
- rewrite some text content
- delete some and add new tour step
closesodoo/odoo#132382
Task-id: 3468585
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
The style was introduced with commit [1]
but then its only usage was removed in [2].
[1]: af89b46c5b
[2]: 59f4d112abf1eb175214614f9a84fc0c7a4af932
closesodoo/odoo#137309
X-original-commit: 22ccb0e795637864706a9933a23f605590a1f36e
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Steps to reproduce:
1. Accounting > Invoices > click any unpaid invoice
2. Register Payment (doesn't matter if it's full or not)
3. Click the info (i) button next to the "Paid on" below invoice lines
-> Traceback
Before the traceback the unreconciliation button available was not
refreshing the view, which still appeared with "Paid on".
We fix both problems at the same time.
task-id:3516681
closesodoo/odoo#136383
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
Purpose
=======
Always show the sum of a property column if its type is integer or float.
When we group records we don't show the sum, because it will require
to be able to aggregate properties (`properties.xxxxx:sum`) and the
technical cost is too big for the feature it gives.
Task-3468750
closesodoo/odoo#133700
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
This commit fixes the signature in the export by:
- Changing the signature template to remove unnecessary transforms.
- Replacing SigningCertificateV2 with the correct tag. According to https://www.facturae.gob.es/formato/Paginas/politicas-firma-electronica.aspx the signature follows the XAdES ETSI TS 101 903 format which contains the tag SigningCertificate instead.
- Correcting the way the signature node was removed in the _get_uri_function.
closesodoo/odoo#137321
X-original-commit: e4d92f37da41e7e5efaeb82b4adfff669083fb23
Signed-off-by: William André (wan) <wan@odoo.com>
Using freezetime to decorate a TestCase can have strange effects.
It looks like an override but monkeypatching the
setUpClass/tearDownClass. It started breaking between python 3.10.6 and
3.10.12. See pr message for more details.
closesodoo/odoo#137215
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
The goal of this commit is to fix two problems in the Many2one field:
1. At setup, the field is considered to be isFloating when its value is false.
2. When "xxx" is encoded and "Create xxx" is selected, the field is still
considered to be isFloating even the selection.
isFloating should only be true when the user is performing a search, when
they have made their choice isFloating should be set to false.
These problems should result in the external button not being displayed
in these two cases. Currently, the button is displayed correctly due to
a bug in owl. The bug in owl causes all Components that have executed
evaluateExpr with record.evalContext will be render each time record.update
is called. For example, for Many2oneField, it is the call to dynamic.context
in extractProps that will cause the rendering of the Component Field
containing Many2oneField. This will trigger a call to onWillUpdateProps
each time record.update is called, and will modify isFloating to make it correct.
In order to fix OWL without introducing any bugs, we're going to fix these problems.
How to reproduce after OWL is fixed:
====================================
Case 1:
------
- Go to a form view with an field "x" (with an onchange) and a many2one field
- Create a new record (the many2one field is empty)
- Edit field "x"
- The onChange returns a value for the many2one
Before this commit:
The external button is not displayed
After this commit
The external button is displayed.
Case 2:
------
- Go to a form view with a many2one field
- Insert "blabla" in the many2one
- Click on "Create blabla".
Before this commit:
The external button is not displayed
After this commit
The external button is displayed.
closesodoo/odoo#137212
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, Even if the user doesn't have access to the timesheet still
user was able to see the "Allocated Hours" in Project tasks. which is part of
the timesheet.
After this commit, if the user doesn't have access to the timesheet then
the user won't be able to see the "Allocated Hours" in Project tasks.
task:3472646
closesodoo/odoo#137135
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Decorator 5 changed the default decoration method from a transparent
exec-ing to wrapper functions. This makes the decorators visible to
the profiler, and breaks one of the profiler tests as the stack traces
now differ between using decorator 4 and decorator 5. Amongst other
concerns, this is an issue because debian bookworm has updated
decorator to 5 (.1.1), and the next ubuntu LTS (which should be 24.04
hopefully codenamed Nefarious Nematode) will do the same (Ubuntu has
been providing decorator 5 since 23.04).
5.1 added a `decoratorx` function which corresponds to the old
exec-based `decorator`, however it doesn't have a `decorate`
version. So we have to flag the wrappers, instead of decorate-ing the
original method with them. This seems to have the same semantics so
why we were using `decorate` is not entirely clear why we were not
doing that previously (neither
b1e83fd7b8 nor #25383 really provide
explanations). Possibly because pylint is a dum-dum and requires
ignoring one of its rules?
Implement in 14 since it doesn't hurt even though the test in question
does not exist yet.
closesodoo/odoo#137323
X-original-commit: 52e92904eca3cdeaee734b0a83e2d3fb463e8b56
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
The initial motivation of this commit was to ensure that the qunit
test suite doesn't stop when an error is thrown in a test, which
could happen if the error was thrown "sufficiently close to the
end of the test". Indeed, the "unhandledrejection" event being
async, it was sometimes triggered after the end of the test, when
the service registry was already reset, and the check of the
presence of the error service was wrong, so the error event wasn't
default prevented (e.g. await makeView(...) and the view crashes
at render time).
This led us to rework in more depth the way we deal with errors in
tests. Here are a few behaviors we want (probably not exhaustive):
- an error in a test must never end the suite (executed in py)
- an error in a test must always make the test fail, except if the
error is expected in the scenario, which one must be able to
state
- a test must always wait for potential unhandledrejection events
to be triggered before ending.
- ideally, we don't want to have to deal with unhandledrejection
in each test throwing an error (in order to prevent the suite to
stop)
To achieve this, we come with the following solution. We introduce
a new assertion method, "expectToThrow" which allows to state that
during the test, we expect errors to be thrown. It takes a list of
error messages that will be compared at the end of the test with
the errors that have been thrown during the test. If they differ,
a qunit failure is pushed and the test fails. If an error occurs
in a test and "expectToThrow" hasn't been called, qunit is directly
informed of the error and a failing assertion is done, make the
test fail as well.
If the error service isn't available in the test environment, we
apply the logic above when an "error" or and "unhandledrejection"
event is thrown. If the error service is available, we wrap the
default handler (typically the one that handles everything that
hasn't been handled by specific handlers, like tracebacks) and if
we get to it, we apply the logic above. This means that one must
call "expectToThrow" if
- the error service isn't deployed, or
- the thrown error is handled by the default handler, because
it is something like a traceback (errors like UserError,
ValidationError are graciously handled by the RPCErrorHandler)
and thus never reach the default handler.
In all cases, we prevent default the event such that the error
doesn't make the python test end.
Finally, to ensure that "undhandledrejection" events are handled
before the test ends, we wait, in the qunit lib, for a setTimeout
before ending the test, which ensures that all such events have
been dispatched.
closesodoo/odoo#137120
Related: odoo/enterprise#48211
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
This traceback arises when the user tries to activate
'l10n_it_edi_sdicoop_register' without 'l10n_it_edi_sdicoop_demo_mode'.
To reproduce this issue:
1) Install 'l10n_it_edi' without demo data
2) Open 'Invoice/Customers/Customers'
3) Set the value of 'Codice Fiscale' field for all customers
4) Go to the 'Configuration/Settings/Electronic Document Invoicing' block
5) Now activate 'Allow Odoo to process invoices' twice
Error:- "KeyError: False"
[1] On the '_set_l10n_it_edi_sdicoop_register_demo_mode' method,
'edi_mode' variable is getting value through 'l10n_it_edi_sdicoop_demo_mode'.
When the user is not activated 'l10n_it_edi_sdicoop_demo_mode', 'edi_mode'
value will be 'False'.
Here 'edi_mode' is used in '_create_proxy_user' method and in that
'_create_proxy_user' the '_register_proxy_user' method is used, in
which the 'response' variable is getting value with the help of
'_get_server_url'method.
[2] But '_get_server_url' method returns 'proxy_urls[proxy_type][edi_mode]'.
Because the user did not selected'l10n_it_edi_sdicoop_demo_mode',
the 'edi_mode' value will be 'False', Which leads to the above traceback.
This commit will resolve the above issue by selecting default value 'demo',
if no 'l10n_it_edi_sdicoop_demo_mode'.
See:-
[1]
https://github.com/odoo/odoo/blob/8a13ca14d3fd251bbf85b1d8949b9d3c6ea76119/addons/l10n_it_edi/models/res_config_settings.py#L81-L92
[2]
https://github.com/odoo/odoo/blob/8a13ca14d3fd251bbf85b1d8949b9d3c6ea76119/addons/account_edi_proxy_client/models/account_edi_proxy_user.py#L84-L89
Sentry-4457787457
closesodoo/odoo#136771
X-original-commit: d6f9a0015c9f82fd7719883f604ad4d808332485
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: Altaf Shaik (alsh) <alsh@odoo.com>
Before this commit
==================
Currently, when we try to modify the BoM Overview report from the studio then
it's return traceback.
Steps to produce
================
- Install Manufacturing(`mrp`) and Studio(`web_studio`)
- Now open Manufacturing and click on the studio icon
- click on the reports button and select BoM Overview report
- Now you can see the traceback
After this commit
=================
With this commit, no more errors occur when we try to modify reports from the studio.
closesodoo/odoo#137175
X-original-commit: 00785e729ab3aaf650102c0ca8b14f9855744574
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Signed-off-by: Bhavin Patel (bat) <bat@odoo.com>
On update/upgrade we should keep current password policy if its
already set
closesodoo/odoo#137326
X-original-commit: c27257914b47b6fda6d4349f9e553abbbfa53347
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Xavier Alt (xal) <xal@odoo.com>
Issue:
If the user does not pass hide_label options then the tooltip appears twice.
Fix:
In this commit we have removed the null tooltip.
Example:
<field name="kanban_state" widget="state_selection" />
task-3475416
closesodoo/odoo#137281
X-original-commit: d39cfca349d5b623eb87f71f9996b3794de24378
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Prakash Prajapati (ppr) <ppr@odoo.com>
Steps:
- In ``stock.production.lot`` list view, use the filter 'Expiration Alerts'
Issue:
Every lots with ``product_expiration_alert`` set to True are returned but also the ones
with ``product_qty`` set to 0.0.
Reason:
The ``StockProductionLot.product_expiration_alert`` represents lots with expiration before or equal to the current date
but don't consider the quantity of product on hand.
Solution:
After discussing with Thomas (THD), and Tiffany (TIC) the solution is to add a new custom search function on the compute
field ``product_qty`` that will be used with the 'Expiration Alerts' filter to solve the problem.
opw-3474622
closesodoo/odoo#137251
X-original-commit: 09f1a45ccbb8b463e7d9326a25c2b0b18173b133
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Signed-off-by: Eteil Junior Djoumatchoua (etdj) <etdj@odoo.com>
The error is caused by this commit: https://github.com/odoo/odoo/commit/e21c17fae8a29c8ee04883b27d761b8ce13cf5b7
Steps to reproduce the bug:
- Enable Storage location in inventory setting
- Create a storable product “P1”:
- Tracked: SN
- Create a purchase order with 1 unit of P1
- Receive product:
- location: WH/stock/shelf 1
- SN: S1
- Valide the delivery
- Go to the product form
- update the quantity:
- new quant:
- Location: WH/stock/shelf 2
- SN: use the same as shelf 1 (S1)
- You will receive a warning informing you that S1 is already used in
another location (this is expected), but the quant is still created
with this SN.
- Now try to clear the quant or refresh the page.
Problem:
You will always get a user error: "Quant's editing is restricted, you
can't do this operation." This occurs because the field "sn_duplicated"
is computed, and the write function is called to set it as True.
However, since this field is not included in the allowed fields,
the user error will always be triggered.
opw-3511463
closesodoo/odoo#137206
X-original-commit: 3a7b781dc1fad41ca0120c48f7587edb6d7adafe
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Co-authored-by: William Henrotin (whe) <whe@odoo.com>
Previously, the custom value of an attribute was not saved in the
database when selected via the point of sale or Self Order. The only way
to see this value was via the product name.
Now, this custom value is saved via the `product.attribute.custom.value`
template, in order to follow the behavior of the Sale module.
Others fix in this PR:
- Prevent to pass to payment page when we are in mobile mode. Only kiosk
mode is allowed to do so.
- Hide "Modify" button in the cart page when the line is already sent to
the server.
- Make the language popup behaviour available in mobile mode too.
closesodoo/odoo#136612
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
This commit introduces a new feature to the domain selector that allows
to toggle a new "include archived" option that alters the domain in a way
such that archived records are included or not. This domain part is naive
and may overlap with custom parts of the domain. The special domain part
which includes archived records (['&', <previous_domain>, '|', ('active'
, '=', True), ('active', '=', False)]) is invisible inside the domain
tree but remains visible in the domain code editor.
Also rename the "Match records with xxx of the following rules" statement
to "Match xxx of the following rules".
task-3482381
closesodoo/odoo#135861
Related: odoo/enterprise#47599
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
This commit adds a new snippet to display an Instagram page on the
website using an iframe that embeds the Instagram page.
task-2603045
closesodoo/odoo#133905
Signed-off-by: Benjamin Vray (bvr) <bvr@odoo.com>
Several reports don't include product packing info on them. This is
useful for customers to see that what they bought matches what they
expected and for pickers who need to know which product packaging they
should be selecting from stock. Reports this was added to are:
- Sales orders,
- purchase orders (including RFQs),
- picking operations,
- delivery slips.
Note that we purposely exclude backordered moves since they weren't
deemed to be necessary at the time this feature was created.
Also includes light refactoring to remove repeated code for conversion
of product qty to packaging qty and to make it easier to do this
conversion in the future (i.e. can pass product.packaging without
original record that it was assigned to)
Task id 2927379
closesodoo/odoo#96858
Signed-off-by: Steve Van Essche <svs@odoo.com>
Steps to reproduce the bug:
- Add a "Text-Image" snippet on the website page.
- Take an "Inner content" snippet from the right panel and drag it from
a dropzone to another. It has to be fast so that the order of the "over"
and "out" dropzone events is "over" > "over" > "out" and not "over" >
"out" > "over" as usual.
-> The exited dropzone is not correctly displayed.
The problem is that since [1], the website is inside of an iframe. Due
to that, the snippets menu does not have a direct access to the
dropzones. To solve the problem, the already defined `$dropZones`
variable is used instead of searching the dropzones inside the DOM. For
the snippet editor, the problematic line has been deleted at it is
already handled by `_outPreviousDropzone()`. This is acceptable since
the commit that introduced `_outPreviousDropzone()` ([2]) and the commit
that introduced the removed line ([3]) were both introduced to handle
the case of an "over" after an "over". In other words, as
`self.droppped` will always be `true` when
`self.dragState.currentDropzoneEl` is set and it will always be `false`
when `self.dragState.currentDropzoneEl` is not set, the problematic line
can be removed as it is already handled in `outPreviousDropzone()`.
[1]: https://github.com/odoo/odoo/commit/31cc10b
[2]: https://github.com/odoo/odoo/commit/c6886410603a16b6a3c5fe459d273dd883c110c7
[3]: https://github.com/odoo/odoo/commit/fed5854e32bcddf8b14b8311b2fe542eed990f77
task-3522552
closesodoo/odoo#137255
X-original-commit: 06fde42d3ba0e8be2128cda8e695c5def917f391
Signed-off-by: Benjamin Vray (bvr) <bvr@odoo.com>
**Preliminary note**
The fix mentioned in this commit is already done
in another commit [1].
The below commit message stayed the same for history's sake.
**Before this commit**
A popover would close on outside mousedown event.
This is not sufficient enough, has for instance all the draggable stuff
makes use of the pointer events instead of the mouse events.
This lead to some unwanted behavior, i.e.:
- Open the DomainSelectorDialog
- Open a ModelFieldSelectorPopover
- Try to drag the modal
- The popover remain open and its position is not updated.
The dialog's dragging is fine.
**After this commit**
The popovers will close on pointerdown away events.
Now:
- Open the DomainSelectorDialog
- Open a ModelFieldSelectorPopover
- Try to drag the modal
- The popover is closed and the dragging still works as expected.
[1]: 76665eb400168a6fd6e2b5f5fe099c8c4e9c8a5e
closesodoo/odoo#137247
X-original-commit: c63dbc4ed0a04e34571c2929f43812873b62fd16
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
