For each form action, existing fields can be defined. These existing
fields are references to objects in the ORM. It is possible to put a
domain on the field in order to filter the elements you want. For
example, the "Create an opportunity" action has a "Salesperson" field
that refers to users. This field filters the external users of the
company in order to have only the internal users. Unfortunately,
although this domain is present, it was not taken into account when
displaying the values for the field. This commit fixes this problem and
takes into account the defined domain.
Steps to reproduce the bug fixed by this commit:
- Have the website_crm module installed
- Put a form on a page of the website
- Set the form action to "Create an Opportunity"
- Add a new field
- Set the field type to "Salesperson"
=> The list of users displayed contains external users of the company.
task-3095745
closesodoo/odoo#121903
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
on this case:
1. Reorderning rule with company 1
and related product and product template is shared mean
no company selected and related product template
contain multiple bom with different company.
so using this line
bom = (product.variant_bom_ids or product.bom_ids)[:1]
from this : `product.bom_ids` as product is inherits
by template, it's tried to read all the bom of different
company and different variant too for same template.
and that will raise multi-company issue.
so I think that should be same company as related
stock rules company.
see : https://github.com/odoo/odoo/commit/6825c440d54e38ebee13a5c184aec1a40586de0d
this was generated during upgrade database.
closesodoo/odoo#125571
X-original-commit: 4edab52bdba2bb53345506a3d83f42bfdccfcd8a
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
This commit ensures that the unsplash beacon calls home when an unsplash
image appears on a page.
To achieve this it patches the RPC call when the test URL contains the
test name as parameter. The patch cancels the actual beacon call to
avoid polluting data during the test, but marks the image as having had
its beacon message sent. The test then simply checks if this marker
appears on the image.
task-3360109
closesodoo/odoo#126522
X-original-commit: 1b0f25130b461e7b531548363c680200c7363e7f
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
If the user change a location type of the 'Production' from inventory locations
and installs the 'MRP' module, the traceback will appear.
Steps to produce:
- Install Stock module.
- Inventory > Configuration > Settings > enable the Storage Locations.
- Inventory > Configuration > Locations > Remove the filter 'Internal'.
- Open the 'Production' location and change the Location Type to 'View'.
- Now install the 'Manufacturing' module.
Error: A traceback appears: 'ParseError: while parsing
/home/odoo/src/odoo/saas-16.2/addons/mrp/data/mrp_data.xml:17, somewhere inside'
At the time of installing the MRP module, it will search for the production
location using the location type as the production here - https://github.com/odoo/odoo/blob/f65a9bffe2cbc03b2efc969dc205c9ba01ee9ab5/addons/mrp/models/stock_warehouse.py#L65
If the production location is not found it will raise an userError. In this
commit, the production location is created based on the company if not found. It
will lead to the above traceback.
sentry-4215564628
closesodoo/odoo#126514
X-original-commit: e8ce51dd0b5024820eee6d5e60a3a3017a0e36f6
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Parth Solanki (paso) <paso@odoo.com>
The menus added in the server data which are used in mockServer did not
reflect a realistic menu configuration. This was brought to light when
trying to fix the addition of links to ir.ui.menu inside a spreadsheet.
See task 2821480
Related ENT pr: https://github.com/odoo/enterprise/pull/42885closesodoo/odoo#126497
X-original-commit: 128475e8c29f8493b01710342179a5c468897c61
Related: odoo/enterprise#43209
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
The label of a facet with type "comparison" did not have any
background color. We set it to be the same as for the label of a facet
of type "groupBy".
closesodoo/odoo#126496
X-original-commit: b0527528ee73b503ffbfef491b2389018c119376
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
The label of a facet of type "comparison" had the role "button" while
click on it has no effect. That role should be reserved for the label of
a facet that is associated with a domain (e.g. a facet of type "filter").
X-original-commit: 4c649abf491b32c218769b0bb1eba19881dedbb0
Part-of: odoo/odoo#126496
Steps to reproduce:
===================
- Go to Quality -> Quality Control -> Quality Points.
- Create new Quality point, using `Receipt` operation, control per operation.
- Go to Inventory -> Operations -> Receipt -> New
- Add whatever product with a quantity.
Issue:
======
The validate button is displayed even when the quality checks are not done.
Added back the `show_validate` condition as this field's compute is overridden
in `quality_control` to also check whether there are still quality checks to
perform.
closesodoo/odoo#126385
Task: 3376811
X-original-commit: d52e146da2980e1c144aa7a9d6c8082bf6bf7adb
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Since [this other commit], initializing the color picker could trigger a
traceback. The traceback was due to the fact that for users to be able
to drag/move the color picker as they wished across different frames, we
needed access to the document of all the frames on the page.
Unfortunately, if one of these frames was not of the same origin, a
traceback was displayed. This commit corrects how we collect documents
from frames on the page, by only taking those whose document we have the
right to see (which do not raise a cross origin error). I didn't succeed
to reproduce the bug locally, but I got it on the runbot with theme
Nursery / Kiddo by dropping the block banner on the page, the error
appears because the block contains a vimeo video. In fact, you just need
to have embedded content (youtube / vimeo / ... video for example) start
edit mode, click on the block containing the video and the error is
displayed.
[this other commit]: https://github.com/odoo/odoo/commit/63bf363d302fe9f93a824fa6f1ff3bbe21f98088
runbot-22573
closesodoo/odoo#126447
X-original-commit: b22c1d942374014e0d50e5429c3f89cc1ca18173
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Before this commit:
When importing `stock.quant` with two lines with the same product and
different counted quantities, only the last line is taken.
After this commit:
Each line creates a `stock.quant`, even if a similar Quant exists.
The records will be merged at a later time by `_merge_quants`.
Steps to reproduce:
1. Create a storable product
2. Go to Inventory > Operations > Inventory Adjustments
3. Create a file with two lines with the same product,
and different counted quantities
5. Favourites > Import Records & upload the file
OPW-3340017
closesodoo/odoo#126480
X-original-commit: 45f7368222ead5df600992c66f0da56b3a7e959a
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Walravens Mathieu (wama) <wama@odoo.com>
When parsing an email containing an xml attachment, the `email` python
module will decode the base64 attachment using the charset or ascii if
the charset is missing.
In some cases, the payload is in UTF-8 but the charset is omitted. This
results in replacement characters for the non ASCII characters.
The solution is to force the charset to UTF-8, since it is a superset of
ASCII that should not be a problem.
NB1: Omitting the charset for text/xml is not recommended. See the RFC
(section 6.4): https://www.ietf.org/rfc/rfc2376.txt
opw-3144519
closesodoo/odoo#126474
X-original-commit: e3a5b46c7b4f5030e165a6d943ec2275aea5d583
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Signed-off-by: Julien Van Roy (juvr) <juvr@odoo.com>
Currently, it's not possible to check the 'Peppol Bis 3' option on the
journals of Italian companies, since Italy is not present in our mapping
`COUNTRY_EAS`.
The EAS for Italian companies may be the codice fiscal (code: 0210) or
the VAT number (code: 0211). See
https://peppol.agid.gov.it/en/news/expiration-validity-codes/
Use the VAT number by default, and add it in our mapping such that the
option now appears for Italian companies.
opw-3346572
closesodoo/odoo#126462
X-original-commit: 92784a0a230c7e93e3ed9fb215376cbbf5ba1362
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: Julien Van Roy (juvr) <juvr@odoo.com>
Adding base translation files for l10n_sa_edi as well as arabic translation
closesodoo/odoo#125610
X-original-commit: 52e96a5ca8a051d8a1a57e1606b4b1b9e810ba7f
Signed-off-by: Josse Colpaert <jco@odoo.com>
- kanban view progressbar based on status
- new first column 'New' with the welcome mail template
- create date column renamed to 'applied on' and moved to front
task 3346175
closesodoo/odoo#123293
Related: odoo/enterprise#42098
Signed-off-by: Kevin Baptiste <kba@odoo.com>
This traceback raises when user not selected 'Employee' and only selecting
'Check In' and 'Check Out', while creating a new attendance.
To reproduce the issue:
1) Install hr_attendance
2) Open Attendance and create a new record
3) Give values to only 'Check In' and 'Check Out'
Error: "AttributeError: 'bool' object has no attribute 'upper'" appears.
On '_compute_worked_hours' method calendar variable is getting value from
employee_id and that calendar timezone is used to get timezone.
https://github.com/odoo/odoo/blob/937d207028ab9bc1d3d332dc6dfe25f0de045026/addons/hr_attendance/models/hr_attendance.py#L50-L60
Therefore in the above use case, when triggering the compute method,
because of 'calendar' is depending on 'employee_id' and when
employee is not selected, it will leads to the above traceback.
Sentry-4274226351
closesodoo/odoo#126465
X-original-commit: 31491e40d2505c03d76e6c802435ad1dafa71c52
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Latams need more fields for VAT and Odoo Milk broke
how these fields are displayed.
opw-3382698
closesodoo/odoo#126461
X-original-commit: 960d47ccc9db2ae69836a5f1ed7bff163b051a42
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Before, when instantiating the taxes for France in a Belgian
company through a French fiscal position (multi-vat),
a traceback would be shown because the cash based transition
account would not be retrieved in the correct way.
By checking the existing accounts (which
are created on the fly for multi-vat) instead of browsing the record
and also, by allowing no account at all, we avoid tracebacks and the
taxes get created.
closesodoo/odoo#126473
X-original-commit: 85f45e37c4ad9503dcc96c321d26504bce3de2c0
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
before this commit, The Kanban view for project tasks includes a subtask button,
a remaining hour timer, an activity button, and assignees in its lower section.
However, when the task has subtasks and timesheet entries, these buttons appear
in the Kanban view, causing the view to lose its structure somewhat.
This commit includes reducing the right margin of the activity button and
remaining hours to provide enough space for other elements in the kanban view.
Additionally, the Lock Icon for private tasks has been given a left margin to
separate it from the activity button
task-3289941
closesodoo/odoo#126446
X-original-commit: eff472e39642bb29e5d4615fcfe1255c00ffc5ef
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Issue:
In the portal view of the project AGR project has 11 Tasks on the list view
but when you click on it, inside there are 12 tasks, not 11
Cause:
The Kanban view of the project includes a button for task
count, which displays the total number of open tasks in the project.
It seems that the task count button displays the correct count because the form
view of the task includes a default filter for 'Open Tasks'.
The form view of the project-sharing feature does not have the default filter of
'Open Tasks'. As a result, the count displayed by the task count button in the
kanban view is different from the count displayed in the list and Kanban views.
Fix:
In this commit, a default filter is passed through the context to ensure that
the task count displayed by the task count button is the same as that displayed
in the list and Kanban views.
task-3289941
X-original-commit: 96304e9b237c06a5d0b459d304df3afbf7607f04
Part-of: odoo/odoo#126446
The code snippet removed by this commit had no useful effect, as
`selection.addRange(range)` a few line above triggers
`OdooEditor._onSelectionChange`, which repositions the toolbar
elsewhere.
The result was a "glitch": the toolbar would briefly be displayed over
the top left corner of the media before finally being displayed above
(or below) it.
This commit removes such undesirable effect.
task-3347942
closesodoo/odoo#126445
X-original-commit: f0272411f6cab059cc8bc2ceed37d9ce59ffe80c
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Nicolas Bayet (nby) <nby@odoo.com>
Signed-off-by: Rodolpho Cammarosano de Lima (rcdl) <rcdl@odoo.com>
Before this commit the position of the arrow was incorrect when the
editor is inside an iframe.
For the calculation of `arrowLeftPos` we need the difference between
the selection rectangle border and the toolbar's left position.
While `correctedSelectionRect.right` is relative to the current iframe's
borders, `left` is relative to the top document's window, as it has been
offset with `parentContextRect.left`. We need both values to be relative
to the same referential in order to make this calculation make sense.
task-3347942
X-original-commit: 8bad3a3fb00d59498455205e8d286a38adaf1335
Part-of: odoo/odoo#126445
Before this commit, an error in the toolbar position happened when the
editor was inside an iframe and the iframe's window had scroll bars.
Steps to reproduce:
- go to the Market Automation app (enterprise edition)
- create new campaign
- add new activity
- create a new mail template by typing a name and selecting "create and
edit"
- select the "plain text" theme
- add a lot of content in order to have the scroll bars
- scroll down
- select something to display the toolbar
The `scrollX` and `scrollY` variables in `_positionToolbar` are ment to
correct the floating toolbar position in case the document in which the
toolbar is mounted has some scrolloffset.
As the floating toolbar is always mounted on the body of the top
document, this is the document to watch for scroll offsets, and not the
inner document when the editor is mounted inside an iframe.
task-3263463
X-original-commit: fb080218def7c47e7b96cf284d613fc03b8325f6
Part-of: odoo/odoo#126445
When a field had an error (required, wrong format etc), upon submission
of the form there would be a JS traceback preventing the page to work
anymore (the Donate button would spin forever).
This is because the code was not adapted to the Bootstrap 5 migration.
It seems like this code to update the config's content is not required
anymore, as without it the content is correctly updated through the
existing `.popover()` call a line above.
You can ensure that by simply omitting your email and send the form, it
will tell you that the email is required. Then just type "a" in the
email field and send again, it will tell you that the format is not
correct.
Somehow, it seems to also be the case in Odoo 15 in Bootstrap 4,
removing those line do not break that.
Some fixes were made at [1] and [2] about the same issue but somehow
people just fixed their own case, while grepping `.config.content` would
have easily found this one too.
[1]: https://github.com/odoo/odoo/commit/37546006940f99c8860e89997ed7a623abd5fa72
[2]: https://github.com/odoo/odoo/commit/0cff1dc2967cafeb8964ed0802c309d3bb7f7525
opw-3381196
closesodoo/odoo#126444
X-original-commit: 9e46ceea801d5044f5db4fee65d5980c64cfa23b
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
In case we use multi company and a user does not have an employee
in every company which is quite normal (mostly you are employed with
exactly one company), the calendar is skipping the provision of the
unusual days like public holidays or the working schedule.
To be able to access and see the calendar in such a case we fallback
to the company calendar and fixed a domain for the public holiday
retrieval whereas the public holidays are not assigned to an employee
but the company or the companies chosen to be displayed.
closesodoo/odoo#126420
X-original-commit: d80a3965b7356f9d6b1294cf428667a1057a272b
Signed-off-by: Kevin Baptiste <kba@odoo.com>
When processing the buttons in the header of the arch,
the listArchParser did not use the method on this.
This was a significant drawback when trying to extend
the behavior of the parser.
After this commit, the processing of the button goes
through the existing method on this, making it possible
to extend that behavior. Note that for the processing
of the other buttons in the arch, this modification has
already been done earlier.
task-3072937
closesodoo/odoo#126400
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
+ update PO and POT files
+ unify i18n and i18n_extra
+ rewrite traditional Chinese to simplified Chinese
closesodoo/odoo#126396
X-original-commit: 02c6c2bed691f263a383636c5209aba5c8c6cf57
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
The customer was having an issue where they would create an expense from an email with the wrong cost on the expense.
Then when they would try to change the price on the expense record it would seem find all the way up until the journal was posted.
Issue:
When creating an expense from an email the unit_amount is updated instead of the total_amount.
This would cause issues if you had an attachment because when you would attempt to change the amount through the front-end this unit_amount would never get updated because it was set and there was an attachment (line 265).
However, when you would create a journal entry from this expense, because it has the unit_amount != 0 it would provide the unit_amount instead of the total_amount.
Thus propogating the original number from the email even if it was updated between the time of posting and the creation of the expense from the email.
Solution:
Implement an inverse function on total_amount that will update the unit_amount to total_amount_company.
This will cause the unit_amount to stay up to date with the total_amount while also taking into account currency.
opw-3286372
closesodoo/odoo#126388
X-original-commit: c2588824edc732bea40b1a8f6e5248b3d318b361
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
In the website settings, one of the fields allows you to switch settings
from one website to another. Unfortunately, as soon as the user did this
the record was considered to have changed (dirty) and therefore required
a save when it wasn't necessary. The previous commit prevents the header
settings (like the website switcher) from dirtying the record. This was
really necessary because as soon as a user had several websites, it was
impossible for him to access certain settings on all these websites
(except the first one). As soon as the setting performed an action, a
save was required (because the record was dirty) and the user was
redirected to the settings again.
Steps to reproduce the issue before the previous commit:
Install website
Have multiple websites
Go to Settings > Website Settings
Change the website
=> The user is notified that the record has changed and needs to be
saved, which is not true. So far it's annoying but not critical, but if
the user continues:
Activate the "Extra step during checkout" option
Click on "Configure Form"
=> The Save/Discard dialog appears because the record is dirty.
Click on "Save"
=> The user is redirected to the settings page again and cannot access
the form configuration of the second website. (it is the same issue for
most of actions).
The previous commit fixes the issue and this commit adds a test to
ensure that the users are able to change settings of multiple websites.
task-3265100
closesodoo/odoo#126387
X-original-commit: bed37396839891da04126a71b3d6a6e5e56672b0
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
When a user changes a header setting, the record should not be marked as
dirty. If the user clicks on a button, the save dialog should not be
shown.
Next commit will bring a functional test and "steps to reproduce" of
this issue in website.
task-3265100
X-original-commit: 1a64fd83f8be677b76ad97a11928859c63709972
Part-of: odoo/odoo#126387
Co-authored-by: "Guillaume (gdi)" <gdi@odoo.com>
Steps to reproduce, on SaaS only, not reproductible in standard:
1. Start a new SaaS Trial on saas-16.3
2. Install helpdesk, setup an incoming mail server
3. Send an email, one that should create a new helpdesk ticket
4. Traceback, request has not 'is_frontend` attribute.
This commit doesn't solve the root issue, it only makes it possible to
use helpdesk again. Using getattr/hasattr to access request.is_frontend
SHOULD NOT be necessary since [HTTPocalypse] BUT there are some rogue
controllers that bypass the normal flow of execution and fail to meet
the expectations of the new http stack.
This commit only makes the code robust to a missing attribute in this
very case as this is a recurring problem (unusable helpdesk). The root
problem is unlikely to be located nor in http_routing, nor in helpdesk.
THIS SOLUTIONS OF USING `getattr`/`hasattr` TO ACCESS `is_frontend` MUST
NOT BE REPLICATED ELSEWHERE WITHOUT PRIOR CONSULTATION WITH PEOPLE IN
CHARGE.
[HTTPocalypse]: https://github.com/odoo/odoo#78857
See-also: https://github.com/odoo/odoo/pull/99667
See-also: https://github.com/odoo/internal/pull/1902
opw-3359740
opw-3365843
closesodoo/odoo#126386
X-original-commit: c808719619167a582dd28420ff2979b57102d2ab
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
As the leave is deducted from the needed time to work
in case for example Home Office which is configured as
working time (other) is handled like a real leave (absence)
which will lead to an extensive overtime instead the difference
to the work entry defining the work time.
A domain clearing out this missing link and variation
cleans up this misalignment and therefore overtime will
be computed correctly.
closesodoo/odoo#126373
X-original-commit: 02a679d6ab7db49c8338471e5fc85c1141f8e877
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: Wolfgang Taferner <w.taferner@wtioit.at>
Currently, if we have a look at the field "Due date" Or "payment terms", the placeholder "terms" seems confusing, no one knows that it will open the "payment terms" list from there as a label of the field is "Due date"
closesodoo/odoo#126362
Task-id: 3340547
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
This PR fixes an alignment issue for the attachments in the
chat windows. Indeed, those attachments were always displayed
to the left while it should be to the right in case it was
uploaded by the current user.
closesodoo/odoo#126355
Signed-off-by: Didier Debondt (did) <did@odoo.com>
The ZATCA edi has an onboarding process which happens per journal.
A private key is generated for the company and with the data from
the company and journal a CSR is made to get a certificate to sign the
invoices. In that process that contains multiple steps (see account_journal.py),
we also have to send the compliance files which are some example (simplified or not)
invoices/debit and credit notes. We have a separate folder with those files
and also use them in the tests. For the onboarding, they still need to be signed however.
For the sending of the customer invoices themselves, UBL 2.1 is used, but
with ZATCA style adaptations. That is why we inherit from that class
to be able to add those specific adaptations. This UBL needs to be
signed XadeS and in this case we need to do the hash with the sign information
present but with empty tags.
For ZATCA invoices, as is the case with Ticketbai, the previous hash is needed
for the next invoice and is stored per journal. (so we have a chain of hashes)
Tests written by Simon (smdc)
closesodoo/odoo#126353
X-original-commit: caf6b0f2e09e7175221894cbb6d22bd6306c4e53
Signed-off-by: Josse Colpaert <jco@odoo.com>
For SA, we need to be able to filter on the taxes exported, as
certain taxes should simply not be reported in the UBL.
X-original-commit: 6019e809b4eedfd5ba56e5f8b39ac4e830131390
Part-of: odoo/odoo#126353
+ to VAT Taxes to comply with ZATCA and provide a better demo VAT number
X-original-commit: 03a0179dbbcda153f5212d104a9550568ed5d222
Part-of: odoo/odoo#126353
How to reproduce the bug
========================
1.Open the register page of an event
2.Do not pick any ticket
3.Click Register
=> an traceback is raised
Technical
=========
'?.length > 0' statement was checking the length of the array instead of the
values of the array.
This issue comes after this https://github.com/odoo/odoo/pull/120437
After this commit:
==================
Now the traceback will not raise.
Task-3329432
closesodoo/odoo#126352
X-original-commit: 1c47606cf1cd56c4d0980c7419c508e37c90f58f
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Steps to reproduce:
-------------------
- create a stage without selecting a project.
Issue:
------
The new stage is inaccessible.
Cause:
------
When the project is not defined, the following ORM command is used:
`[6, False, []]` for the `project_ids` field.
Solution:
---------
When we create a project stage (project task type),
it is essential that we link it to a project.
Add the possibility to override `_get_default_project_ids`.
Set default project as first fsm project if not project in
the context.
opw-3322992
closesodoo/odoo#126338
X-original-commit: 69c09684e37accdaf1248f31a7c97f0c20434b76
Related: odoo/enterprise#43134
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Thomas Lefebvre (thle) <thle@odoo.com>
It was possible to create inconstancies in accounting entries by forcing to sum apples and pears.
Steps to reproduce
1. create a journal entry using at least one account with a secondary currency set
2. balance and save that move
3. change the secondary currency on the line and force it to a different value than the one on the account
4. save. You'd expect an error pop up but the constraint doesn't trigger and you're allowed to save/post
opw-3340697
closesodoo/odoo#126336
X-original-commit: e6581f39ec5d550db924aa7a86dd12f511f87958
Signed-off-by: William André (wan) <wan@odoo.com>
Steps to reproduce:
- Go to Accounting > Vendors > Vendors > Accounting tab > Add a new bank account
- Enter a bank Account Number
- Toggle Send Money
- A validation error is thrown
This is because the widget `boolean_toggle` triggers a save
at each change of value by default, so it needs to be desactivated.
opw-3306639
closesodoo/odoo#126333
X-original-commit: 1717a3ee9d2455eaa61010765be08707a491c93f
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Claire Bretton (clbr) <clbr@odoo.com>
With [1] and [2], the colorpicker / colorpalette were implemented. In
both cases, for the custom colors hue / saturation / lightness selection
we listened to mousemove/mouseup events on the whole body / document.
That is to be able to start dragging the color cursors from inside the
colorpicker to anywhere on the screen (the cursor being confined into
their own box of course).
Problems occur when iframes come into the equation. Indeed, from that
moment, listening to mousemove events on an unique document is not the
way to go as mousemove over inner iframes will be ignored. This should
not be the case anywhere in 15.0 (that this original commit targets).
The only iframe there should be the mass_mailing one and in that case,
the colorpicker is inside the iframe so it should not be a problem.
However, [3] (then fixed by [4]) were meant to tackle a similar problem
(although [3] seems to say the goal was to ignore mousemove outside the
iframe which is the opposite of what this current commit tries to do:
listening on the whole screen). However, by doing so, a memory leak was
created as the document on which the events were bound was not properly
cleaned as the `destroy` which unbinds the events was not adapted. That
is the main reason why this commit targets 15.0 (although, the solution
here still makes sense generically in 15.0 and should make the code
simpler and easier to understand).
In 16.0, however, the iframe situation is a problem: the website builder
colorpickers are now in the main document but the edited content is
inside an inner iframe. In that case, listening to the main document's
mousemove/mouseup events makes the colorpicker only work when not
hovering the edited content (which could be acceptable but not perfect).
Note that during that website builder refactoring, [5] worsened the code
of [3] and [4] to do exactly that. Later, [6] was made to solve an
unrelated problem and actually woke up that worsened code, not
understanding what the new undocumented `ownerDocument` option was for
(it will stay like this in stable from now on, as it will be not used
anywhere anymore... hopefully). Because of that, the situation became
the opposite: dragging inside the colorpicker did not work until the
edited content was hovered. And because of that functional fact, an even
more visible problem was created:
- Click on a snippet
- Select a custom background color using the hsl selection
- Hover a non custom color (like nearly always the case "by mistake"
after configuring a custom color, your mouse just moves over the non
custom colors) => your custom color is lost
This was because the chain of events that were listened inside the
colorpicker were gone (because of the combination of [5] and [6]). In
the end, this only revealed the shortcomings of the implementation in
[1], [2], [3] and [4]: we should not try to search which frame we have
to listen to: we should listen to the whole screen. This commit solves
the issue by listening to the top window document and all its inner
iframes, also fixing the memory leak mentioned earlier.
task-3332711
[1]: https://github.com/odoo/odoo/commit/29f0c0a186a9a60d6e5b7f026c305d689b6fc807
[2]: https://github.com/odoo/odoo/commit/99910b526ed792235a778863b993d10cf4e77cd7
[3]: https://github.com/odoo/odoo/commit/4fb33f7f8d6955a44fbb7c94c7d204e9baa09707
[4]: https://github.com/odoo/odoo/commit/f1b26335a286a47f685b7830db97c21e6fefd68b
[5]: https://github.com/odoo/odoo/commit/03c552690b15cbf2e7d6b7812386ac64042219af
[6]: https://github.com/odoo/odoo/commit/418c1178301e28b4bd1412da6d0558e219060830closesodoo/odoo#126313
X-original-commit: e03158e6da45d83c977b7cf51f0f998343dc6fd6
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
It is more conventional to bind extra events in the `start` of widgets
instead of in their `init`. Indeed, the handlers often make sense only
if the widget is already in the DOM.
Related to task-3332711
Part-of: odoo/odoo#126313
Guillaume (gdi)