Before this commit when we have a synced event with google and then we toggle the all-day field
changes didn't reflect on google side
This happened because google uses two separate fields for start/end.
1. dateTime (used for normal events)
2. date (used for all-day events)
when one of them is set, the other must be null.
Before this commit when we did a patch update, we set only one, but forget about the other which raises an error.
closesodoo/odoo#157664
Task: 3681668
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Currently, an error occurs when the user tries to add an order with toppings.
This is because before 17.0, [1] got values like `[6, False (1, 2)]`, where
we found the `values['topping_ids_1'][0][2] (ids (1,2))`. But after 17.0,
[1] got values like `[[4, 1], [4, 2]]`. As a result, it cannot be found in
the `[0][2]` index at [1].
This commit fixes the above issue by using 'convert_to_cach()', which returns
the ids from [[4, 1], [4, 2]]. Apart from that, this commit also improves the
code by adding a loop to get topping IDs for each topping.
[1]-https://github.com/odoo/odoo/blob/039407cf2954ce6298aa8af7aff251a1cefdc39b/addons/lunch/models/lunch_order.py#L99
sentry-4627940064
closesodoo/odoo#142701
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
**Current behavior:**
Adding an attachment to a mail template record associated with
the survey invite wizard will not cause the attachment to
populate the relevant field when actually sending a new survey
invite email.
**Expected behavior:**
The attachments linked in the email template which is used by
the survey invite wizard will appear in the form when sending a
survey invite.
**Steps to reproduce:**
1. In settings, go to the email templates management page
2. Select the Survey: Invite template and upload some
attachment
3. Go to the Survey application and click on one of the surveys
listed, observe the lack of attachments despite having the
email template with the attachment selected
**Cause of the issue:**
The survey invite wizard never uses its template's attachments
to modify/update its own attachment_ids field.
**Fix:**
Make the attachment_ids field a stored computed field.
opw-3709830
closesodoo/odoo#162499
X-original-commit: 1fcc11a2ca8e18d10eaac51ce20773596db183e2
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Vincent Ethan <etvi@odoo.com>
Currently, when you refund an order that was paid with bank, thus not rounded, the refund is rounded wich result in a difference between the original order and the refund.
This also happens when the original order was paid with multiple payments and one of them was not rounded and the other was. The refund will be rounded as one single payment. This also results in a difference between the original order and the refund.
Steps to reproduce:
-------------------
* Setup a rounding method with a precision of 5.0
* Create a product with a price of 138.0
* Open the POS and add the product to the order
* Pay the order with 2 payments, one bank of 55 and one cash that will be rounded to 80.
* Validate the order
* Go in the backend and refund the order
* The refund will be rounded to 135.0
Why the fix:
------------
The new behavior after this fix:
* When refunding the entire original order, the amount to refund should be equal to what the customer paid on the original order (thus taking into account the rounding).
* When doing a partial refund, the amount that should be refunded correspond to the base price of the article(s) selected.
The issue was about the fact that refunds differed in prices compared to the original order. With this fix, there could still be a difference in the prices if a customer comes multiple times to do a partial refund and end up refunding the total order. This difference exists only if the original order was paid with rounding and will be maximum the rounding defined.
Since this is a rare event, we consider this difference to be acceptable.
Post-fixup:
-----------
The function `_get_rounded_amount()` was modified as we are not computing cash rounding when refunding anymore.
opw-3701574
closesodoo/odoo#162416
X-original-commit: f8e78cdee3dac64a3ac3d8da529aea398cdb7393
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Sarah Bellefroid (sbel) <sbel@odoo.com>
Co-authored-by: Robin Engels <roen@odoo.com>
At the moment, if EMV QR is selected on the invoice where the country does not support EMV QR an error is raised.
However, this error is also raised if EMV QR is selected but the bank account is not set. The following error is raise
`No EMV QR Code is available for the country of the account False.`
This commit adds a check to ensure the bank account is set and raise a better error message.
Task# 3868467
closesodoo/odoo#162500
X-original-commit: e6ca281b691e75dd9c12fb110f80f444c21729de
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
The `test_accepting_recurrent_event_*` tests make sure that accepting recurrent events on google side reflect in odoo.
The test was failing because of the following:
when retrieving the invited attendee, the test used `self.assertEqual(event.attendee_ids[1].state, expected_states[i])` assuming that organizer will be at index `0` and invited user at index `1`.
However the list of `event.attendee_ids` is ordered by create_date.
And we create both organizer and attendee with the same command at the same time: `partner_ids=[Command.set([self.organizer_user.partner_id.id, self.attendee_user.partner_id.id])]`
So we might have organizer at index `1` and invited attendee at index `0`. This resulted in the indeterministic behavior of the test.
To fix this issue:
This commit changes how the invited attendee is retrieved, making sure that we always get the right attendee.
fixes runbot-61527
closesodoo/odoo#162279
X-original-commit: 6db2614283abfc035343f021b9cfc52609aa9d44
Signed-off-by: Ahmad Almaghraby (alah) <alah@odoo.com>
Actually if a server is not configured we can click on it and
we are redirect to not reachable page
With this commit it is not possible to click if server is not configured
closesodoo/odoo#162372
Signed-off-by: Yaroslav Soroko (yaso) <yaso@odoo.com>
When the iot run without server we display an certificate error.
This error is useless because we can't get a certificate without server.
Some customer a worry about this error
With this commit we hide this comment if we not connected to a Odoo server
closesodoo/odoo#162371
Signed-off-by: Yaroslav Soroko (yaso) <yaso@odoo.com>
Strings within inline templates are not translatable, so we convert
these templates into standard templates so that they can be.
Task-3761551
closesodoo/odoo#162106
X-original-commit: 5b38d58db1bb7cacd2a5ffa195a3799f2645fdbb
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Signed-off-by: Mohammed Basioni (basm) <basm@odoo.com>
Prior to this commit, some attributes such as "data-tooltip" were not
exported in /static/src/ templates, while "label" was only exported in
them.
This commit adjusts the code to use the same list of translated
attributes everywhere, fixing the problem and making it less likely to
happen again.
Task-3872895
closesodoo/odoo#162250
X-original-commit: 6c272a432cea29fa98d9f2a3e4f454214099f3e6
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Given the changes in [1] and subsequently in [2], which in some way
counteract the RTL adjustment, it is necessary to eliminate the rtlcss
directive from the carousel CSS to ensure the correct behavior.
Steps to reproduce:
- Enter in edit mode.
- Drag and drop an image gallery and a carousel snippet.
- Navigate to the theme tab.
- Add an RTL language (Arabic, for instance).
Bug :
- The images slide in incorrectly during transitions. In RTL mode, when
clicking on the left chevron, the next image should appear, not the
previous one.
If we have three slides numbered 1, 2, and 3
- In RTL mode: Clicking left should navigate from 1 to 2 to 3 and then
back to 1.
- In non-RTL mode: Clicking left should navigate from 1 to 3 to 2 and
then back to 1.
The directional Font Awesome icons (classes starting with `fa-` and
ending with `-right` or `-left`) are not flipped in the mobile viewport
as a result of [3]. Necessary adjustments have been implemented
to prevent this behavior.
Upon investigation, a more significant bug was discovered regarding the
'oi-...-[right/left]' icons. These icons were not flipped appropriately
in the frontend when the webpage context was set to an RTL language. A
pull request has been created and merged to address this issue [4].
More info on rtlcss [here]
[1]: https://github.com/odoo/odoo/commit/ebb61753bf3d3dd8d3f53db088112b9e4beb813d
[2]: https://github.com/odoo/odoo/commit/c48f57ea2538ad51e00ac27d58f8e191781444f3
[3]: https://github.com/odoo/odoo/commit/be375bb2a886edd002f042355455a71fcac4daf5
[4]: https://github.com/odoo/odoo/pull/157214
[here]: https://rtlcss.com/learn/usage-guide/value-directives/#tip
opw-3747848
closesodoo/odoo#162202
X-original-commit: 7f0f750b0d9e45982130742af2ac396d1985612e
Related: odoo/enterprise#60922
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Steps to reproduce:
1- Create an allocation with validity date (e.g. 01-01-2024 -> 30-06-2024)
and another one starts after the first one (e.g. 01-07-2024 -> 31-12-2024)
2- Go to Time off module and select a date in the second allocation's period
3- Click on the Time off type dropdown menu
4- You will see the first allocation displayed not the second one
Current behavior before PR:
The display name of some leaves gets computed in a wrong way.
This is happening because after fetching the right allocation
we compute the display name but this time we don't have
the 'default_date_from' in context so since
it became one of the fields that triggers '_compute_leaves'
https://github.com/odoo/odoo/blob/17.0/addons/hr_holidays/models/hr_leave_type.py#L218:L219
we compute the leaves once again but the target_date will be none
and it will get assigned with today's date in 'get_allocation_data'
https://github.com/odoo/odoo/blob/17.0/addons/hr_holidays/models/hr_leave_type.py#L380:L381
Desired behavior after PR is merged:
This has been solved by saving the date attribute in the context
with another name as when computing the display_name we call sudo so clean_context()
removes the 'default_' context keys. Now when it gets removed we are
going to have the same value but with another name.
opw-3797696
closesodoo/odoo#159917
Signed-off-by: Youssef Bashandy (yoba) <yoba@odoo.com>
Steps:
- Install sale apps.
- Upload a header file from settings with xyz.pdf for
example.
Issue:
- Header/Footer file is not updated according to uploaded
file name.
Cause:
- Header/Footer file name in setting is related and
readonly is should not be readonly in order to update
header file name.
Fix:
- Make settings header/footer file not readonly to
set proper updated file names.
task-3620555
closesodoo/odoo#152007
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
In Shop Floor, consuming less tracked by lots components than expected
gives an 'Invalid Operation: lot/serial number needs to be specified
for a tracked product' error.
Discarding the dialog to fix the quantities makes the production order
disappear from the Shop Floor.
This because of the MO Readiness filter: as the move becomes partially
available, the reservation state goes to confirmed rather than assigned.
closesodoo/odoo#144718
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Currently restarts of the odoo server do not happen at
the end of the installation of all components. The devices are therefore not detected.
With this commit we restart the server when all the components have been installed
closesodoo/odoo#162362
Signed-off-by: Yaroslav Soroko (yaso) <yaso@odoo.com>
Prior to this commit, if a product had multiple attributes, each
attribute would be displayed multiple times in the order line. This
commit resolves this issue by ensuring that each attribute line is
displayed only once.
opw-3849701
closesodoo/odoo#162258
Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>
Start a SMTPS server with client certificate authentication. In Odoo
configure an outgoing mail server with encryption="ssl/tls" and
authentication="certicifate". Load a valid client certificate and key to
use with the SMTPS server then test the connection.
The connection fails because the client certificate wasn't sent during
the TLS handshake.
If you're having trouble running a SMTPS server, I made a script here:
https://gist.github.com/Julien00859/5090d1cff6c02197e5854aabb67bf5ac
It uses aiosmtpd, a light pure python smtp server, install it with pip.
You'll need to copy your snakeoil ssl key + cert inside your /tmp
directory and to expose them to your current user:
# public cert
cp /etc/ssl/certs/ssl-cert-snakeoil.pem /tmp
# private key
sudo cp /etc/ssl/private/ssl-cert-snakeoil.key /tmp
sudo chmod 400 /tmp/ssl-cert-snakeoil.key
sudo chown $USER /tmp/ssl-cert-snakeoil.key
task-3703209
closesodoo/odoo#162297
X-original-commit: b3d7c1fc9c017a4354dc4a6f8abfbf590bc26a51
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
No rounding in the query used to map sale.order.line to
the hr.expense, models leads to some records not being able
to be linked together, because of floating point errors.
Adding a rounding to the key price_unit,
and not filtering on price_unit. Then, using the rounded string versions
of the price_unit in the comparisons adds a more reliable approach.
task-3705179
closesodoo/odoo#162245
X-original-commit: 0f4705be195ac66e1cdf5af39fd509035929556c
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Julien Alardot (jual) <jual@odoo.com>
Currently, recalculating `analytic_distribution` requires access to
`account.analytic.distribution.model`. This breaks BoM creation for
non-accounting users (e.g. MRP managers). This commit fixes the issue by
using `sudo()._get_distribution`.
closesodoo/odoo#162184
X-original-commit: 3872e9365e4d8cc100a6022e934292f6f6802162
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Pawel Fertyk (pafe) <pafe@odoo.com>
Previously, when the odoo server was running on some Windows
installations, it was possible for javascript files loaded directly from
the static folder of an addon to fail to run because the Content-Type
header was set to text/plain instead of text/javascript. This is because
the mimetypes module from the standard library honors the mimetypes from
the OS, in the case of Windows it reads a key in the registry, which can
be misconfigured to text/plain for .js files.
This commit forces the mimetype of .js files to text/javascript to solve
this issue.
closesodoo/odoo#162313
X-original-commit: 64cbe389e698398eee93ebde9c61b2ee79756380
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
Since [this other commit], web_editor can call IAP to generate text via
chatGPT. Unfortunately, an unnecessary param (`version`) was given to
IAP leading to a warning on the IAP side
`generate_content_from_conversation> called ignoring args <version=X>`.
This commit removes this useless param.
[this other commit]: https://github.com/odoo/odoo/commit/386a2fdebf429b0318473e596ed9ac0966d9a8b5
Related to task-3383324
closesodoo/odoo#162249
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Commit f0016849 added the module `sale_async_emails` but not the .pot
file.
closesodoo/odoo#162215
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Versions
--------
- saas-16.3+
Steps
-----
1. Set timezone of User and browser to America/Los_Angeles;
2. go to Time Off;
3. click on calendar to create a new leave.
Issue
-----
Date defaults to the day before the selected date.
Cause
-----
Commit 0a0c6917b5 added a TZ conversion in
JS to add default start & end times for leaves. The issue is that it
assumes the context values are always datetime strings, therefore always
using `deserializeDateTime`, which does a timezone conversion from UTC
to local time, which is incorrect when the context values are date
strings.
For a UTC-7 zone like America/Los_Angeles, it deserializes a date string
like '2024-01-01' to '2023-12-12 17:00:00' (7 hours before midnight). It
then sets the start hour to 7, and serializes it back to UTC, adding 7
hours, resulting in '2023-12-12 14:00:00'. Instead, Jan 1, 7 AM in
America/Los_Angeles should convert to '2024-01-01 14:00:00' UTC.
Solution
--------
Use `deserializeDate` instead of `deserializeDateTime` when the
`default_date_{from,to}` in the context is a date rather than a
datetime. This way, '2024-01-01' gets deserialized into '2024-01-01
00:00:00' local time. When this value gets used for the default hours,
'2024-01-01 07:00:00' local time will get serialized to '2024-01-01
14:00:00' UTC as expected.
opw-3757712
closesodoo/odoo#162203
X-original-commit: 134455167734d101a8ce923043700e5fc8f497bd
Signed-off-by: Levi Siuzdak <sile@odoo.com>
If the "generic" routes (i.e., the ones created from the master data)
are company-specific, the user won't be able to create a new company
anymore.
To reproduce the issue:
1. In Settings, enable "Multi-Step Routes"
2. Enable all companies
3. Inventory > Configuration > Rules:
- For each Manufacture rule:
- If its route does not have any company:
- Set the route's company equal to the one of the rule
4. Create a new company
Error: a Validation Error is raised: "Rule [...] (Production) belongs
to \<new company\> while the route belongs to \<an existing company\>."
Creating a company leads to the creation of the WH and its rules. At
some point, we create/update the global rules. Let's look at the
Manufacture one. We will provide all the required values for its
creation:
https://github.com/odoo/odoo/blob/270d8aa06bb37b4a01f01a7274062e3f88ca2a1c/addons/mrp/models/stock_warehouse.py#L112-L128
As you can see, for the `route_id` field, we try to find a global
route. But here is the issue: in this `_find_global_route`, we will
find the "generic" one thanks to the provided XML_ID. But, step 3,
we set a company on that route. As a result, here, we try to create
a rule for a company X linked to a route that belongs to a company Y,
hence the validation error:
https://github.com/odoo/odoo/blob/dc58d7913131f1f4dbeb0e3337e61e0b21f6f0d9/addons/stock/models/stock_rule.py#L107-L108
OPW-3790512
closesodoo/odoo#162189
X-original-commit: f7131cbb860fe447ee7f31beff3de59da0544bcd
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Steps to reproduce the issue:
----------------------------
1. Enable dark mode
2. Go to Project app
3. Create a new project
4. Click on `See examples` in the kanban
5. Select an example.
Actual Behavior:
---------------
The name of the selected example is in black instead of white.
Expected Behavior:
-----------------
The name of the selected example should be in white.
Solution:
--------
Update the font color of the selected example name to white for better
contrast in dark mode.
task-3602610
closesodoo/odoo#162133
X-original-commit: 60d1580d4bc493c2572ac7c223df3c72f53873bd
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Followup of odoo/odoo@d6d6bee087 : test was not written to be independent
from demo data.
Also update other tour that fails in no-demo mode as portal user has not enough
address value set to continue the tour, compared to demo mode.
Task-3871775
Runbot-56554
Runbot-56553
Runbot-61488
Runbot-58213
closesodoo/odoo#162021
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit:
In systray activity, for some languages, when there were few activities (exceeded a certain
length of text), it would break the line to display the labels.
After this commit:
Now, to maintain the design integrity, the text has been truncated to visually display
the labels like "aujourd'hu.." and maintain the design consistency.
Task-3869856
closesodoo/odoo#162001
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When processing a transaction, the payment method was searched based on
the received code (e.g., 'sepa_debit') that was compared with the
`payment` module's generic codes (e.g., 'sepa_direct_debit'). This
commit ensures that we now compare with provider-specific codes for
Buckaroo and Stripe.
In practice, this mistake had little to no impact as most provider codes
match the generic ones, and we fall back onto the payment method
selected by the user if we can not find a more accurate one based on the
code.
closesodoo/odoo#161883
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
When payment details are tokenized through a validation operation, the
currency to use was usually (except overrides) chosen as that of the
payment provider's company. This sometimes caused compatibility issues
if the selected payment method did not support the company's main
currency. For example, the SEPA Direct Debit payment method only
supports the EUR currency.
This commit allows passing a payment method when getting the validation
currency so that only supported currencies can be returned.
Part-of: odoo/odoo#161883
After this commit, `colorField` is used instead of `cardColorField` to
handle color change from the dropdown of cards in the kanban view.
The value of `colorField` is observed in order to adapt the HTML classes
of `oe_kanban_card` (first `DIV` of `o_kanban_record`) by
adding/removing `oe_kanban_color_X` (where X is an index representing a color).
opw-3823860
closesodoo/odoo#161645
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Achraf Ben Azzouz (abz) <abz@odoo.com>
In the currencies list view, the current rate and inverse rate were swapped.
Their strings were also changed to match the string in the form view.
Currency rates were inversed in the currencies list view.
task-3856386
closesodoo/odoo#160882
Signed-off-by: William André (wan) <wan@odoo.com>
Problem:
When we are in the form view of a product variant, the smart button "Extra Price" shows the number of pricelists for this variant including the archived ones
Steps to reproduce:
- Install "Sales" app and activate the pricelists
- Create a product and some variants
- Create at least one pricelist for a variant
- Archive at least one of these pricelist
- Go on the form view of the variant and take a look at the smart button which shows the number of pricelists including the archived ones
Cause:
The domain that filters the pricelists doesn't take in consideration whether the pricelist is active
opw-3836973
closesodoo/odoo#160876
Signed-off-by: Axel Trémaudant (axtr) <axtr@odoo.com>
Issue
-----
The packing is not displayed on the delivery slip when:
- the product is tracked by lot/SN
- the stock.move state = "Done"
- "Display Lots & Serial Numbers on Delivery Slips" is activated
According to c07258c3f27790eea424cee745b2036a3ef0e8c2, packaging
information should always be present.
Fix
-----
We add packaging information to the delivery slip in the case it
was missing.
opw-3820304
closesodoo/odoo#159448
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Steps to reproduice:
-go to myprofile with hr installed
-go to resume page
-> skills title is duplicated
Reason:
The no_label attribute is set to True but the widget will still display a label.
Expected behavior:
The label should only be displayed once
Fix:
Remove the effectless no_label attribute and remove the separator
closesodoo/odoo#158051
Task: 3815381
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Description:
Add supporting indexes that are used in the queries generated when
openning the accounting dashboard. A query is tweaked to hit
those indexes and avoid `JOIN` where possible.
Benchmark:
Hot loading the default accounting dashboard, default filters and
1 company selected on a staging database with millions of accounting
related entries.
| | Before | After |
|---------|----------|----------|
| Timings | 7.32 sec | 1.6 sec |
Reference:
task-3805835
closesodoo/odoo#157892
Signed-off-by: William André (wan) <wan@odoo.com>
Added a test to verify the behaviour when receiving a negative bill. The
invoice gets imported with negative amounts, but it can't be posted.
When the user tries to post it, they are prompted to turn it into a
credit note with a UserError.
closesodoo/odoo#141485
Signed-off-by: Josse Colpaert <jco@odoo.com>
By default, Bootstrap uses a solid color and dim the element by setting
`$hr-opacity` to `0.25`[1].
Our design comes with a color that is "dimmed by default" since:
```scss
$hr-color ← $border-color ← rgba(currentColor, .25)
```
This commit therefore sets `$hr-opacity: 1 !default`.
At the same time, this also removes the hr background-color that
Bootstrap sets, otherwise it conflicts with the transparent color we are
adding on top of it.
[1]: https://github.com/odoo/odoo/blob/1154556/addons/web/static/lib/bootstrap/scss/_variables.scss#L664closesodoo/odoo#160495
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
This commit fixes a bug where the value of an autocomplete with autoselect
could go into an undefined state where the model value doesn't match the
input value but no change is detected. This would happen on escape press,
scroll and more recently due to https://github.com/odoo/odoo/pull/159333
on click out. To fix this issue, the commit introduces some change in the
autocomplete behavior so that it will no longer select the active option
on click out (blur) when autoselect is active and instead it will revert
the input value to the one stored into the model. Also applies this
behavior on escape key press and scroll for the before mentioned reasons.
Steps to reproduce:
- Go to CRM form view
- Edit the salesperson name to some non existant one and click out (or
scroll or press escape)
Before the fix, the name was stuck to the invalid one but no change was
detected so we couldnt save it. Before https://github.com/odoo/odoo/pull/159333,
click out would select the active option of the dropdown instead (and
launch a dialog for quick create). This is removed because the behavior
is neither intuitive nor practical. After the fix, the name is reset to its
previous valid value instead. This applies to all autocomplete components
with autoselect prop set to true.
closesodoo/odoo#162040
X-original-commit: 9d9026ed0c7bb0af6cf910cc206cf8b55d1b7a36
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Julien Carion (juca) <juca@odoo.com>
Steps to reproduce :
1. click on edit website.
2. click on THEME tab from snippet options.
3. scroll down to input fields.
4. the border width has options for small and large size, which serves
no purpose and were displayed empty.
Purpose:
This commit aims to remove the changes made on [1] which added 2
sublevel options for Border Width for Input Field which served no
purpose.
After this commit :
The Border Width option will not have sub options small and large.
[1]: odoo@388e4bb
task-3771146
closesodoo/odoo#161872
X-original-commit: f35123799408614c0bd50fcb79d147d2f69a84f7
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
In Chrome, if a scroll event is not brand new, its `currentTarget` is
lost.
This commit makes sure that the `currentTarget` of the throttled scroll
event sent to `_onScrollWebsiteAnimate` is kept separately to avoid the
issue in case of throttling delay.
task-3449843
closesodoo/odoo#161850
X-original-commit: 277e9f292a031ed835f4135e597c17dab2fd067d
Signed-off-by: Benjamin Vray (bvr) <bvr@odoo.com>
This is a followup on [1].
In Chrome the event's currentTarget is cleared after events such as
"scroll" are handled. For asynchronously called methods to be able to
access it, the current value of currentTarget needs to be kept.
To help developers that might stumble on this issue when using
`throttleForAnimation`, this commit emphasizes the fact that usage of
that function is not limited to event handlers, and it adds a test case
that illustrates a solution for tracking the lost scroll event target.
No scenario was identified in 15.0, but this could be used as an
alternative solution for [1].
[1]: https://github.com/odoo/odoo/commit/0ba601d2ef5c4e2f846818e78dcd23966d6f563d
task-3449843
X-original-commit: 6cc4cbf2b91d624368c489460a90795921985f6b
Part-of: odoo/odoo#161850
ahmad(alah)