When a domain field value is edited via the debug textarea, no
search_count is done for performance reasons. A single exception is done
when saving the record. Then we check the validity of the domain created
in the debug textarea in order to avoid to save an invalid domain in db
(and get tracebacks,..). The problem is that a search_count can take a
very long time to be executed if the domain is valid. Here we introduce
a route /web/domain/validate in order to quickly check the validity of a
domain and use it in domain field in order to fix the above mentionned
performance issue. Note that the search_count is still done if it useful
but does not have to be waited anymore.
X-original-commit: 40288221c39ff8fba41cd6ac231ab33600dc0cd4
Part-of: odoo/odoo#128913
Co-authored-by: Oliver Dony <odo@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Currently, users cannot deregister from Peppol.
There is an option to migrate away (i.e. request a migration key) but not every provider supports migration.
It is not straightforward to deregister from Peppol once a participant is marked as "prepared for migration",
so the users really should deregister instead.
Also, it is important to run the cron one last time for the user to fetch new documents/message status updates
they've received since the last time the cron ran.
closesodoo/odoo#128867
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Step to produce:
=================
- Create MO of serial tracking product.
- Start workorder.
- Click on continue consumption button.
- Enter quantity to consume then click on validate button.
- Then when we click on Continue button quantity become zero or negative.
Issue:
========
If the product tracking is serial and quantity is already set to 1 in this case
it write the same 1 value in serial tracking order because of that it calls
'_update_component_quantity' method again it will make the quantity zero.
After this commit:
=====================
Prevent the quantity becoming zero.
Task id: 3212121
closesodoo/odoo#128665
X-original-commit: 907129be7efba2a0b68f9bef14c6a22c1be8861a
Related: odoo/enterprise#44183
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
The goal of this PR is to remove all dependency to legacy assets in the wysiwyg because the wysiwyg is loaded on a lot of form view through the html_field, thus defeating the purpose of the legacy assets being lazy loaded.
To remove the dependencies, all the legacy widget that the wysiwyg uses had to
be converted to owl. In order to finish the PR faster, only a partial conversion
of the widgets is done, changing only the part of the code that was necessary
for it to work instead of rewriting the whole widget from scratch. Another pass
should be done to convert all those widgets to fully embrace the owl paradigm.
task-3175256
closesodoo/odoo#118966
Related: odoo/upgrade#4750
Related: odoo/enterprise#42141
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
The goal of this commit is to remove all dependency to legacy in the
wysiwyg because the wysiwyg has to be loaded on a lot of form view
(through the html_field).
To remove the dependencies, all the legacy widget that the wysiwyg
uses had to be converted to owl. In order to finish the PR faster,
only a partial conversion of the widgets is done, changing only the
part of the code that was necessary for it to work instead of
rewriting the whole widget from scratch. Another pass should be done
to convert all those widgets to fully embrace the owl paradigm.
task-3175256
Part-of: odoo/odoo#118966
In a subsequent commit, the ImageCropWidget will be converted into
an Owl component called ImageCrop. To match the new name, this commit
rename the file.
task-3175256
Part-of: odoo/odoo#118966
In order to match the filename with the only classname of that file,
this commit rename `wysiwyg.js` to `MassMailingWysiwyg.js`.
task-3175256
Part-of: odoo/odoo#118966
Before this commit, when recurring meeting were created with alarms, there were
as many cron trigger created as there were events in the recurrence.
After this commit, only one trigger is created for the first event starting in the
future and the next cron trigger is created once the trigger of the first event is
called by the cron.
closesodoo/odoo#118738
Taskid: 3270442
Related: odoo/upgrade#4706
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Before this commit, when a ir.cron was walling _trigger, the ir.cron.trigger
records were not returned. it would prevent to use them later easily without
making a search.
Taskid: 3270442
Part-of: odoo/odoo#118738
Before this commit: Body content is the same as tmeplate
After: Body content is the same as the template
*: hr_recruitement, sale, survey, website_slides
closesodoo/odoo#128953
X-original-commit: 388e340a52fd5775c1702f8952a1e959fa5cef48
Related: odoo/enterprise#44309
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
To reproduce:
1. Create a new mail group with privacy "Everyone"
(menu: Website / Configuration / Mailing Lists / Mailing Lists)
2. As an anonymous user, go to /groups and click on its name
3. A 403 Forbidden error is displayed:
`You are not allowed to access 'Email Aliases' (mail.alias) records.`
This commit is a followup of odoo/odoo@cd2f330bec where global
mail.alias access rights were revoked, so we have to check if alias
is valid as superuser.
closesodoo/odoo#128915
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, only the cross icon "x" top right of the popup would
be able to properly close the popup and set a cookie to prevent that
popup to open again later.
There is no way through the UI to make a button in the popup do the same
behavior.
This commit now add this behavior to any `.btn-primary` element inside
the popup, except a few ones like the newsletter input group button and
the website form submit one.
Note that we have a way in stable to do that, but it's through code.
People have to add the `js_close_popup` class to the button. This class
is there for this reason, but it's obviously limited to tech people
only or our support.
task-3377306
opw-3328135
closesodoo/odoo#124432
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
**Description of the issue/feature this PR addresses:**
- Increase user experience in creating website themes
- Eliminate redundant creation of 1 record leading to unnecessary model
`ir_model_data` contraints error
**Recreate the Situation**
- Install the website module
- Choose `a business website` in line 1, `fashion designer` in line 2,
`get lead` in line 3 on `configurator - step 2`
- Choose random paletee on `configurator - step 3`
- `Build my website` on `configurator - step 4`
- Suppose in this step that we have a bad connection to the api
`https://website.api.odoo.com`, the error `duplicate key value violates
unique constraint` will appear.
**Reason**
- When a user creates a website, the `configurator_apply` function is
called to the api `https://website.api.odoo.com`. If the connection time
exceeds 5s, the `configurator_apply` function will be called again.
Maximum of 3 times
- Each time `configurator_apply` function runs, will create records of
model `ir_model_data` at `set_images` function. This function will
create records with a name field like
`configurator_1_s_cover_default_image`.
- If this function runs again for the second time, it will also generate
a `configurator_1_s_cover_default_image` for the second time. This will
result in a `duplicate key value violates unique constraint` error.
**Before commit:**
- When creating a website theme by industry, if the user's connection to
odoo's api has a delay, it will cause an api contraints error of model
`ir_model_data`
**After commit:**
- Check if the record of model `ir_model_data` has been created before,
if created then skip
closesodoo/odoo#128959
X-original-commit: 56ccf4efeb946e2e0b6ef54b977b6d8b070306ee
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
In Switzerland, states are really important. Each state has its rules, its
language, its culture, its parliament, etc. It's quite frowned upon to send an
invoice/offer or even to have backend management using German terms when we're
in a very French-speaking state.
So in this PR, we will add states in the missing languages
closesodoo/odoo#128954
Task: 3268058
X-original-commit: f309fd06cd46a767fee742ec9f634b46a2edf70f
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Before this commit, livechats in mobile were shown in the "Chat"
tab in both discuss app and messaging menu. This is alright, but
there's a dedicated tab for "Livechat", which was empty as a result.
The intended showing in mobile is to keep livechat away from "Chat",
and instead populate the "Livechat" filter.
Task-3430253
closesodoo/odoo#128934
X-original-commit: cf4b72582bbb52c7cd4bc17733f4dbbc84f9b321
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
If an inactive currency is given as company currency write values,
it is unarchived, but before the company update.
Therefore, if the unarchiving of the currency enables the multi-currency,
a default pricelist will be created for the company, but with the wrong
currency since it still wasn't updated.
This commit postpones the automatic creation of pricelists after the update
of the company, making sure the currency of the pricelist is the expected one.
opw-3423706
closesodoo/odoo#128958
X-original-commit: f7c90e4e1c5b6a3335e7c9b9e209a786d4238434
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
In the context of an urgent htmlField `commitChanges`, there is no time to wait
the response of `rpc` calls, therefore this commit proposes to use the same
strategy as `_toInline` for `savePendingImages` and not await the result of
the promises before a first `updateValue` if the commit is `urgent`.
This will allow to save most of the changes during a `beforeunload` scenario.
ENTERPRISE PR: https://github.com/odoo/enterprise/pull/42644
task-3372343
closesodoo/odoo#128949
X-original-commit: ba94629cb7fd1381871c37d34104f2511a4d4863
Related: odoo/enterprise#44307
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
In 9deb1e6aa902a09c4f invisible duplicate were added for boolean groups.
But the added test could fail on master when installing only base
module: in this case, there is only the group "base.group_allow_export"
that is shown as a selection group because it is the only field of its
category. When we install other module, the field become a boolean group
that is handled by the aboved mentionned commit.
The previous fix and test didn't take this case into account, with
customization this could be a real issue.
With this commit, hidden selection field are also handled and the test
test_reified_groups pass in master when installing only base.
related to #120310closesodoo/odoo#128944
X-original-commit: b22fc41d63bded2435cd330517d407abab5035ee
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Before this commit:
In table selecting a list and on deletion/backspace page crashes.
After this commit:
The selected list is now deleted.
task-3383168
closesodoo/odoo#128943
X-original-commit: c7d3d247269ce27a10da39df5848cc10f9f6627b
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The number of invalidation during the test is quite large and
the crons cal also spam this log sometimes.
Waiting for further cleanup, removing this log to avoid spaming runbot
logs and making them harder to read.
closesodoo/odoo#128921
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Purpose:
--------
This commit makes the the avatars shown in many2one properties in kanban
cards smaller, as they were abnormally big.
Task-342200
closesodoo/odoo#128912
X-original-commit: 9ae4be80c68faafd7a09ea3cbeaf45e9b8eeaa71
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Before this commit, the `keydown` and `keyup` events of the call feature
were in bubble mode, which could prevent them from operating when some
other listeners would prevent the propagation of the event.
Since push-to-talk is supposed to always be usable, the listeners
are now in capture mode.
It was first made apparent with the addition of a `stopPropagation()` in
the `chatWindow` here: https://github.com/odoo/odoo/pull/127638closesodoo/odoo#128897
X-original-commit: 1466a6bc471ed583966e959b47f10bdc64837732
Signed-off-by: Didier Debondt (did) <did@odoo.com>
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
This commit partly reverts 59afbf6686 and
provides an alternative solution. In this solution, records.web_read()
returns a list of dicts where the key 'id' corresponds to each record.id
in records, which enables to reliably relate each record to its values.
This also fixes the implementation of web_read() on new records where
the fields contain a reference field with some context.
closesodoo/odoo#128878
Signed-off-by: Raphael Collet <rco@odoo.com>
Considering the valid odoo version in the manifest version
The message before of this commit was:
Modules should have a version in format ``x.y`` or ``x.y.z``
It looks like it enforces to removing the odoo version part as invalid
But it is not, in fact, it is already supported
It is important since OCA enforces ``{odoo.version}.x.y.z`` format
It was already discussed here:
- https://github.com/odoo/odoo/pull/118420#issuecomment-1635047100
The message after this commit is:
Modules should have a version in format `x.y`, `x.y.z`, `16.4.x.y` or `16.4.x.y.z`.
Notice the Odoo version "16.4" is the current {odoo.version} for the moment this commit was done
It avoid confusing about the valid formats to use
closesodoo/odoo#128810
Signed-off-by: Christophe Simonis (chs) <chs@odoo.com>
The opportunity is taken to make the feature reactive.
Also fix traceback if favorites can't be fetched from external API.
Part of task-3265211
Part-of: odoo/odoo#128799
This commit uniformises the different discuss option
panel by introducing a dedicated component.
Before this change, every single discuss panel would
look different: font size/weight, text in lower/upper
case, margins...
Moreover, in the chat window, the close panel button
was absolute positionned which could overlap with the
content of the panel. Moreover, the cross icon looked
strange with the one of the chat window header.
This commit introduces the `ActionPanel` component in
order to solve those inconsistencies and replaces the
cross icon by an arrow left one.
part of task-3332872
closesodoo/odoo#128742
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
*: point_of_sale, pos_adyen, pos_hr, pos_mercury, pos_restaurant
Adds online payments in Point of Sale using the payment module.
The pos_online_payment module is meant to be used by shops for paying online instead of using a physical terminal and by restaurants for paying an order either from the paying station or in the self-order process (smartphone used to order and pay online).
The module depends only on point_of_sale (and account_payment to support online payments).
The online payments support for self-order will be added in another commit.
The feature can be used by configuring a special pos.payment.method for one or many pos.config.
Operation:
The frontend session user can enter one or several online payment method lines (with or without other payment methods).
When he validates the order, if the online payment amounts are valid, a popup with a QR code is displayed on the frontend screen and on the customer display. This QR code allows the customer to open the payment page to pay online for the order.
The amount to pay for an order on the payment portal is the remaining unpaid amount or a lower amount if several online payments lines are used. Therefore, at any time, the customer will be able to pay the amount of the order that is unpaid, without requiring a staff operation to update the amount to pay.
When an online payment is done for a POS order, the generated account.payment is linked to the POS order through a pos.payment that is created with the online payment method configured for the pos.config, and the POS order paid process is triggered (it is the responsibility of the server to finalize the validation of POS orders that have at least one online payment, and not the responsibility of the POS session web client). If for any reason, there is no longer any online payment method configured for the pos.config of the order, a new one can be created automatically and exceptionnaly used to link the done payment with the POS order. This guarantees that any online payment saved by the payment module will be linked to the POS order.
The session web client is notified of successful online payments through web socket communication, to make the cashier screen automatically and quickly react to payments.
If several online payments are used for a single POS order, they are processed one after each other.
Working principles:
- The POS session web client is not allowed to save online payments on the server. Only the Odoo server, which handles the payment, can save online payments for a POS order.
- The POS session is only responsible for saving the order (especially other payment methods) and the next online payment amount to pay (in case of several online payments) on the server before the online payments are made by the customer, and for displaying the online payment status and the link (QR code) to open the payment page.
That means that modifications that are made after the order is fully paid are not taken into account by the server.
- Before validating an order, the POS session checks with the server if any online payment has been made for that POS order. If the user wasn't aware of one, the validation process is aborted, notifying him.
- The sensitive online payments data is received by the frontend user with RPC to the server when validating an order, cancelling an online payment or receiving a notification through the POS bus (web socket communication).
This data is used to update the cashier data for the specific order.
- No sensitive information is sent through the POS bus (web socket communication).
Indeed, the bus communication is only protected by the name of the channel, and there is no mecanism to prevent several attempts. Therefore, no sensitive information is sent through it, only a notification to invite the local browser to do a safe RPC to the server to check the new state of the order.
- Online payments for a POS order cannot be modified or removed when they succeeded. Checks ensure to never allow an online payment to make the total paid amount greater than the total amount of the POS order.
- If the frontend user clicks on the "Cancel" button of the online payment popup, the order can potentially still be paid online. Indeed, the order will be removed from the server only if it was added only for the online payment flow, and any order that is not paid can be paid on the online payment portal (if the customer has the web link).
This behavior ensures that in a shop, starting an online payment and then cancelling it doesn't prevent the user to close the POS session. And it ensures to don't delete a draft order that is used for other flows, like in a restaurant or when there are trusted POS configs.
Payment portal features:
- The payment portal pages of a POS order are protected with its access_token.
- If the amount of the order has changed when the customer clicks to pay, an error is fired to notify him and give him the choice to continue or abandon the payment.
- An exit_route argument (an URL) can be passed to allow the customer to exit the payment portal at any time (with a button), which could be used for self-order flow.
- A button to go back to the payment page is displayed when an error occurs during a payment transaction, which allows the customer to retry a payment without needing to scan again the QR code.
- If the customer is not logged in in the payment portal (most frequent case), it is considered as the public user partner for the payment flow to don't give him privileged access to sensitive data like payment tokens.
- The accounting process of online payments for POS orders is made in the same way that the pos.payment.method that have split_transactions to True.
- The POS customer of a POS order has no link with the customer making an online payment for that POS order.
- The payment portal is made using the pos.order id and not the pos_reference because the latter is not guaranteed to be unique.
Some tests have been written, especially one that simulates a whole online payment flow starting from nothing, creating an order, requesting an online payment, faking this online payment by doing web requests to the payment portal, then finally closing the POS session to check that there is no accounting issue.
The design of the payment portal is temporary.
closesodoo/odoo#123237
Task-id: 3276404
Related: odoo/enterprise#41776
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Purpose
=======
Make it possible to attract attention to a small section of a text document (e.g. task spec, knowledge article, etc.) via a new "bloc" called "Banner".
Specifications
==============
Add 4 commands in web_editor.
Each command will add a banner of the following types and will come with their associated icons:
- Banner Info: alert-info - info-circle
- Banner Success: alert-success - check-circle
- Banner Warning: alert-warning - exclamation-triangle
- Banner Danger: alert-danger - exclamation
Task-2782426
closesodoo/odoo#120690
Related: odoo/enterprise#41716
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
Make it possible to attract attention to a small section of a text document
(e.g. task spec, knowledge article, etc.) via a new "bloc" called "Banner".
Specifications
==============
Add 4 commands in web_editor.
Each command will add a banner of the following types and will come with their
associated icons:
- Banner Info: alert-info - info-circle
- Banner Success: alert-success - check-circle
- Banner Warning: alert-warning - exclamation-triangle
- Banner Danger: alert-danger - exclamation
Task-2782426
Part-of: odoo/odoo#120690
This commit add a new utility method to check if the selection (current cursor
position) starts inside one of the given selectors. This method will be used,
notably, for filtering some commands inside some HTML Elements of the web
editor. Some commands should not be available within certain elements like
table, custom behaviours (knowledge app) or banners (that will be introduced in
the next commit).
Task-2782426
Part-of: odoo/odoo#120690
Before this commit, the o_not_editable class was used as a way to
dynamically set contentEditable on a node. This was little more
than a convulated way to write `node.contentEditable = false`.
Moreover, the o_editable class was not treated the same way and
did not set contentEditable to true.
This commit turns those two classes into markers for contentEditable
values in html. Once those classes are set, the contentEditable
attribute is updated accordingly. It is not updated dynamically
afterwards. For dynamically setting a node as editable or not, use
the contentEditable attribute directly.
Task-2782426
Part-of: odoo/odoo#120690
Prior to this, there was no way to shut an active session you didn't have the
access to anymore or close every active session remotely.
Adding the RevokeAllDevices class, it is now possible to close every open
sessions, including the one you are performing the action on of the account
you are logged into via the Account Security page in the preferences.
This system is based on the principle that every open session uses the password
hash to maintain it. When the hash is computed, salt is added to it to make it
not reversible. Thanks to that salt, it is possible to change the user's
password's hash without changing the password. Therefore, the flow of this
addition is the following :
1. User clicks on the button and uses his passord to confirm identity.
2. User's input is used to check his identity (_check_credentials()).
3. User's input is used to refresh the password hash in the db (_change_password()).
4. User is logged out.
This adds a way to close all sessions remotely and improve user's control over
their account and therefore their security.
task-3191567
closesodoo/odoo#113899
Related: odoo/upgrade#4951
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Steps to reproduce:
- Deliver an SN-tracked product with the Destination Package set (put in pack button also sets this).
- Return that product without setting the Source Package (you can also click "put in pack" which will put the product in yet another pack).
- This already results in two lines with the same SN in the same location, one with +1.00 and one with -1.00 quantity.
- Deliver that product again and put in pack.
- Now there's three lines with the same SN in the same location, two with +1.00 and one with -1.00 quantity.
Bug:
source Package isn't set bydefault when confirming the move_line
we update the stock quantity for that lot_id and Package set to False
the existing quantity has a Package set so it is filtered out and a new
negative quantity is created
Fix:
set the source Package on the return
opw-3179388
closesodoo/odoo#128874
X-original-commit: ca168f7fbcbb8a300a8fa0b46f79a6c116b5aa93
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Steps to reproduce:
1. On website, drop a snippet
2. Type something, than undo it (ctrl + z or click undo button on the
sidebar)
3. On the sidebar, hover over the buttons of "Content Width" and/or
"Height" to get a preview of those actions
4. Perform a redo with ctrl + y.
Explanation:
One can only redo changes when in a state resulting from an undo, that is,
redo is the undoing of an undo. Once new changes are introduced after an
undo operation took place, a redo cannot be performed anymore.
The OdooEditor handles this at the history steps level. If there's a
a history step with state "undefined" (not resulting of undo or redo)
that is more recent than the most recent step with state "undo", a
redo is not possible.
But, before this commit, this was not handled at the current step's
mutations level. The presence of mutations in the current step did not
prevent a redo, and applying a redo on top of those changes could lead to
unexpected results, as the changes resulting from the reversion of undo
step interacted with the mutations performed subsequent to the undo
operation.
The presence of mutations in the current step when about to redo is
possible by previewing changes as described above, as they perform
DOM mutations without committing them into a history step. The same
effect can be achieved by selecting some text and hovering over the
colors of the colorpicker. Theoretically, any asynchronous compound
command (multiple calls to execCommand within historyPauseSteps/
historyUnpauseSteps) will add mutations to the current step without
committing them, while still offering the user the possibility of a redo.
This commit makes sure that mutations in the current step are treated
as an uncommitted draft and are discarded before applying a redo, mirroring
what is done for the undo operation.
task-3339304
closesodoo/odoo#128873
X-original-commit: 6ab6927c0fc4c4a1c838251953a29512dd0d3835
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This commit separates the test that was added together with the "not
move images twice within image wall" fix because it requires additional
fixes for working in 16.0.
task-2990053
closesodoo/odoo#125758
X-original-commit: f4e8ca1eca1193a72a0b1d21cbc4af5093907ca9
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
*: web_editor
During the masonry layout calculation of the images wall snippet, the
image height is used to determine into which column each image is
inserted. Their height is zero until they are actually loaded. Because
of this, the column into which an image is inserted can be wrong.
This becomes more obvious in 16.0 because since [1] the image selection
is lost when moving it within an Image Wall because it is replaced by a
clone when using masonry mode.
This commit makes sure that the images are loaded before taking their
height into account when building the masonry layout.
This involves two changes:
1. By awaiting `wUtils.onceAllImagesLoaded(this.$target)` after the
insertion of each cloned image, we are sure that the reached height of
each column is available before deciding where to insert the next image.
2. Before re-selecting the previously selected image, we need to be
sure that it is loaded. Therefore we keep track of the last masonry
layout operation and await for it. This way, we rely on the await of
the last image as described in point 1.
Additionally, as of 16.0, there is a race condition with
`snippet_option_update`: in some situations, `notify` is called before
`snippet_option_update` is completed, and before the masonry layout is
applied. To make sure it is completed, the whole notify is run within
the mutex through a `snippet_edition_request` event.
To uphold the stable policy, making `mode` async will only be done in
master.
In stable, a new `_modeWithImageWait` is added which is called only
for the situations that causing an issue, and which enables the fix
of the masonry layout.
In 14.0, it is used when computing the layout from `start` and
`addImages`.
In 16.0, it is also used in `notify` when images are removed or moved
around - because masonry clones the images.
In master, it is always applied.
Steps to reproduce:
- Drop an Images Wall.
- Add four images, the first one being taller than the others.
=> The fourth image sometimes appeared below the tall image.
[1]: https://github.com/odoo/odoo/commit/0d43aec24baad6420e0fe150a9c19d33c0b74198
task-2990053
X-original-commit: 9605d9ba7b26885d66e861e0e5c7dff7489031f9
Part-of: odoo/odoo#125758
Since [1] the "Images Add/Remove All" buttons are on top of the
background options in order to appear as the first option for the
"Image Wall" snippet.
This makes the JS related to the handling of the options of that
snippet created twice: once for the buttons above and once for the
options below.
Because of this, events are registered by both instances and they both
get notified on option update. Therefore, when an image is moved, it is
moved twice instead of once.
This commit differentiates both instances, and makes the one that
handles the "Add" and "Remove All" buttons be the only one that works on
the images.
In stable the differentiation is done with conditional statements.
In master the instances should be of distinct classes.
Steps to reproduce:
- Drop an "Images Wall" block.
- Switch the "Mode" option to "Grid" instead of "Masonry".
- Select the wine glass image in the third column.
- Click on "Move to previous".
=> The wine glass image ended up in the first column because it was
moved twice.
This commit also fixes a typo in the `reoder_items` name introduced
by [2].
[1]: https://github.com/odoo/odoo/commit/b6494fcf284edcddaa36b5fcfd407a6d7186fbd7
[2]: https://github.com/odoo/odoo/commit/e8713dc078b5c1799917f238a4c32b4289aceb8a
task-2990053
X-original-commit: f8724b55162b2550734dbe6e0454c406d6e4241c
Part-of: odoo/odoo#125758
Inside the Images Wall snippet, images are dispatched to columns
depending on the height already reached by each column. This computation
relies on a sub-pixel height which leads to a confusing behavior.
This commit rounds the sub-pixel height to a visible pixel height to
avoid the confusion.
Steps to reproduce:
In the default images of the Images Wall snippet, the third image (sign)
is one pixel taller than the other ones.
- Drop an Images Wall snippet.
- Select the "sign" image.
- Move it to the first position.
(Because of another bug involving a race condition with the loading of
images, you might observe a different behavior. Move to first position
again to recompute the layout several times.)
=> The compass image moved to the first column.
task-2990053
X-original-commit: d0c15abd17e151a8861cc950116b11111d694bb3
Part-of: odoo/odoo#125758
