The RPC that the m2o widgets used by snippet options make are cached at
the widget level. When two m2o widgets make the same RPC, they are
indeed made twice. This commit just move the cache outside of the
widget instance and thus makes it so the same RPC made across multiple
m2o are cached.
Note: this was particularly visible because all main snippets have the
"Conditional Visibility" option which uses 3 m2m widgets. At each drop
of such main snippet in the page, the option is created and the 3 m2m
widgets made their RPC. Then each further drop of snippet made the exact
same RPC for no good reason.
In the future, the system should be further improved to not require
those RPC on initial drop and clicks, especially as the "Conditional
Visibility" m2m widgets are hidden by default. This fix focuses on
fixing the generic m2m widgets.
closesodoo/odoo#102800
X-original-commit: 8e08c896df9ed5a7a0e559f1dbd8812f87908a39
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When a snippet option uses a m2m widget, the domain used for the
internal m2o widget which allows to select records evolves to receive
the subdomain `['id', 'not in', <selected-ids>]` with `<selected-ids>`
indicating the m2m records which are already selected.
M2o rpc are cached... based on the whole query object from which they
are created. The domain is part of that query object.
Both those concepts actually conflicted: the initial RPC when no ID is
selected was made with no subdomain, while the subsequent RPC when no ID
is selected were made with the `['id', 'not in', []]` subdomain. The
cache system did treat the resulting domains as different requests. Now
we avoid adding the useless `['id', 'not in', []]` subdomain as it
should already have been done without a cache system in place.
Note: this was particularly visible because all main snippets have the
"Conditional Visibility" option which uses 3 m2m widgets. At each drop
of such main snippet in the page, the option is created and the 3 m2m
widgets made their RPC with the initial domain. Then on click on the
snippet, a new RPC was made with the problematic subdomain, making the
first click on snippets being needlessly slower.
In the future, the system should be further improved to not require
those RPC on initial drop and clicks, especially as the "Conditional
Visibility" m2m widgets are hidden by default. This fix focuses on
fixing the generic m2m widgets.
X-original-commit: 017a468547eafa3e34f584379d3f05b3ed1db487
Part-of: odoo/odoo#102800
The website edition system is based on a main mutex to guarantee the
order of user manipulations. Meaning that if an user follows any flow
really quickly, each part of the flow should be guaranteed to be done
in the order the user asked for, independently from the duration of each
part. The mutex system to ensure that is not robust yet though, or at
least it is not easy to use and should probably be replaced by something
more easier to use in the future. Indeed, some operations are badly
implemented around this mutex.
This is the case of the drag and drop of a snippet into the page. Drag
and dropping a snippet is a long series of operations, to name a few:
1. The user mousedown on a snippet thumbnail
2. The user drags the snippet around
3. The user drops the snippet in a dropzone
4. We scroll the page to the position of the snippet
5. The snippet is built (options' `onBuilt` methods)
6. The snippet public widgets are started
That whole series of operation has to be reduced to an atomic work to
be added to the mutex queue. Meaning that for example, if the user
manages to click on the save button while he is dragging a snippet
around... the editor should only save the page after the whole series
of operations of the drag and drop has completed. This is not the case
right now: the mutex lock is released between (4) and (5) because we
have too: (5) and (6) use the mutex themselves and would thus induce
a deadlock if we only release the mutex after (6) as it should be. This
means that during the scroll to the snippet (4), if the user manages to
click on the save button, the save operation will be scheduled to be
done before (5) and (6). It is thus technically possible to save a
snippet which is not built** (even if it would not be critical most of
the time). Worse, before building a snippet, its options have to be
instantiated... and that operation is not mutex protected so this is
probably (not 100% sure) possible that this happens:
a. Drag and drop a snippet. During the scrolling, click on save.
b. End of scrolling, the mutex lock is released, we create the first
option and its widgets as part of the onBuilt process. Creating each
widget is async, once the first one is created, the saving process
starts as it was scheduled in (a).
c. Saving the content, destroying all snippet options and their widgets.
d. Continuing building snippet options widgets started at (b)... but
previously-made ones were destroyed at (c)... possible crashes***.
Fixing all of this probably requires a change in the system, maybe the
use of multiple mutexes, maybe the saving operation can always be
delayed at the end of the queue somehow, ... but this requires some more
thinking and probably not possible in stable. In stable, it could be
enough to disable the saving entirely during drag and drop (like drag
and drop of another snippet is currently disabled during another drag
and drop). This will be done in another commit if this is decided.
Meanwhile, this commit just changes the behavior in tours for now:
waiting for drag&drop to fully complete before clicking on save, like
an human would.
** It is possible to reproduce by using the ALT + S shortcut: start
dragging a snippet which has a onBuilt method in its options, hover
the dropzone where you will drop, ALT + S to save (the editor waits
you drop your snippet), drop your snippet -> the snippet is saved and
the edit mode is left... but the onBuilt was not executed.
*** a crash was indeed found during a specific theme tour (out of ~30
Odoo themes because of this after the other commit of this current
PR). After those other commits especially, it is also possible to
reproduce with the ALT + S trick, although not consistently. It may
be linked to the specific last snippet added by that theme tour
instantiating specific options. But as explained saving just after
drop is an issue independently from this potential crash problem
(snippet not built, etc).
X-original-commit: e96167ae20d2a143d7def4347166b37e158003b0
Part-of: odoo/odoo#102800
Prior to this commit, the language of the snippet menu would be the same
as the snippet content. This would cause issues if the user's language
was not the same as the website they were editing.
This commit fixes that by displaying the snippet menu in the user's
selected language but getting snippet content in the website's language.
This commit also fixes SEO data not being saved according to the
website's displayed language. Prior, it was saved according to the
user's current display language.
This commit also introduces a test for a fix made at [1] that
targets a previous version of odoo.
[1]: https://github.com/odoo/odoo/commit/db5d1eae2086ff338d8211af70c2f88240393c36
task-2687506
closesodoo/odoo#102799
X-original-commit: 55a978aa86967581956f855a1c5db33b7425bd15
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Commit [1] keeps the snippet cache alive through different
instance of the website snippet menu.
This allows for the user to switch pages, even apps, while
keeping the snippets in cache, decreasing the startup time of the
snippet menu.
However, the cache is not invalidated when switching website or
installing a new theme.
This commit adds a `invalidateSnippetCache` property to the
websiteService. If this property is set to `true`, the cache will be
invalidated next time the menus loads its snippet.
This property is currently set to `true` when changing website and
switching theme.
[1]: https://github.com/odoo/odoo/commit/03c552690b15cbf2e7d6b7812386ac64042219af
task-2687506
X-original-commit: bb503962a36f3798c50049f2844e7b288b632955
Part-of: odoo/odoo#102799
Commit [1] added back the user context to every RPC called from the
legacy env when it's mapped to the WowlEnv but in doing so, overrode
the params' context keys.
This is incorrect as the params could very well have context params that
are different from the session's params for a reason.
For example, in master, after [2], editing the menus of a website
displayed in a language different from the user's will lead to incorrect
languages in the context when the page is saved. This is cause the
language in which the page is edited is passed as a context param, and
the language of the user is in the session (under the same `lang` key).
[1]: https://github.com/odoo/odoo/commit/d959638e23a92cf880049a760c42da33e5908f41
[2]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
X-original-commit: 8cdb2293f294558c3bea4ed59a49e0f52b3d217e
Part-of: odoo/odoo#102799
Before this PR, the chat window hidden menu dropdown would have been
opened to the bottom of the corresponding button. The issue is that,
this button is position at the really bottom of the page, causing the
dropdown to be outside of the page.
This PR fixes this issue by adding the missing `data-bs-toggle`
attribute.
task-3011161
closesodoo/odoo#102765
X-original-commit: a4b69feb13852dd13160564bce3b0ae1cb453c0b
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Stockbauer Matthieu (tsm) <tsm@odoo.com>
It is technically nearly impossible to delete a company
when it actually dealed with customers
(emitted invoices, received payments, ...).
Hence, if you want to get rid of a company,
for instance because you closed one of your subsidiaries,
giving the possibility to archive your company,
thanks to an active field, would be the best way to go.
We are hesitating to do a related field to the
`partner_id.active`, but we are a bit afraid
some people archive the partner linked to their company
for other valid reasons than get rid of their subsidiary
(such as avoid changing the address of their company
by mistake through the Contacts app),
while still wanting the company itself to be active.
So, we make it an independant column at the moment,
so we have the actual stored column in case we need it,
and will do a related stored to the partner
later on if we change our mind.
Manual forward-port of #102801closesodoo/odoo#102586
Signed-off-by: Olivier Dony <odo@odoo.com>
Before this commit, sending a message on a livechat whose visitor closed
the chat window would have resulted in a traceback being shown to the
visitor. This was occurring when a message was sent by an operator or the welcome
bot. An other related issue occurred when sending the feedback to the welcome
bot.
This commit fixes those issues by correctly guarding calls to
`publicLivechatGlobal.chatWindow`.
task-3010725
closesodoo/odoo#102752
X-original-commit: 524fc3e4cb0e63029e774e97de687998ccf06909
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Stockbauer Matthieu (tsm) <tsm@odoo.com>
The editor's toolbar is at the very bottom of mass_mailing's sidebar,
making dropdowns pretty awkward as they often require the user to scroll
down to see them. This extends the editor's toolbar for mass_mailing so
all dropdowns become dropups instead.
closesodoo/odoo#102734
X-original-commit: d4b5527113a6092063cba3409d870c5c45a8cd03
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
In mass_mailing, the paragraph alignment dropdown menu is wrongly
positioned by Popper since the upgrade to Bootstrap 5. Other dropdowns
in the toolbar had the `data-bs-display="static"` attribute but it seems
that paragraph alignment was omitted by mistake.
task-3002168
X-original-commit: 8a372800b9a035893d9f9ecdf7afce17aef3f1b2
Part-of: odoo/odoo#102734
The iframe in mass_mailing is self-resizing in order to avoid having two
vertical scrollbar side by side. This failed since the conversion to OWL
due to the vertical offset added when resizing having become
insufficient. This adds a class to the <html> element of the iframe to
identify when it's in the context of mass_mailing so we can remove the
overflow visible style that is not needed in this context. This allows
us to remove that vertical offset altogether since the scrollbar
disappeared.
X-original-commit: 4f538911d68afdeca0253f15c9e8ffdbed4e995c
Part-of: odoo/odoo#102734
One of `mass_mailing_tour`'s tooltips was overflowing the body and
causing a horizontal scrollbar. This repositions it so that doesn't
happen.
X-original-commit: 4e2ccb51991cbe4428f084f333c57b78851f73b0
Part-of: odoo/odoo#102734
Before this commit
When clicking on "create" from a form view in mass_mailing, the
"template picker" was not presented.
task-3002100
closesodoo/odoo#102725
X-original-commit: 664d5982663517e8e2f2f87b355fd7d3c72285f1
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The "Switch to 1 or 2 weeks calendar" are breaking the layout by
being placed just before attendances_ids on the Working Hours sheet.
With this commit, the buttons are moved in the header of the form.
task-2996235
closesodoo/odoo#102711
X-original-commit: e81e03e6511c4d975bd7da4748f11747faf38251
Related: odoo/enterprise#32539
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: phwa-odoo <phwa@odoo.com>
Purpose: The number of 'Late activities' are displayed on the kanban card.
The number excludes the activities for the hired applicants. Yet, once we
click on it, we are redirected to the activity view, which included the
later activities. On the one hand, this is not consistent, but on the
other hand, one might still be interested in those activities later on.
Thus the best way out is to put the filter for the "Running Applicants".
This filter will filter out the applicants in hired stage, but if we are
interested in them, one could just remove the filter.
task - 3001375
closesodoo/odoo#102691
X-original-commit: 16e025de14be3ace07191ab153259ed17b174748
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Gvaladze Sopiko (sgv) <sgv@odoo.com>
`activeActions` is a set of boolean values determining what actions
(i.e. 'create', 'delete', etc.) can be performed on the current view or
subview (x2many).
Before this commit, the x2many fields used a different naming convention
than the one set on the views (e.g. 'canCreate' instead of 'create').
This caused mismatches when subviews would try to rely on the parent
view `activeActions` to define their own. This also introduced a bad
design where the "type" of `activeActions` would be determined by that
same mismatch.
Another issue was that the list renderer did not always check for the
existence of activeFields in its props, despite defining them as
optional.
This commit unifies the names of the active actions accross views and
x2many fields, while adding a "type" property to it s.t. its owner
can determine what context it finds itself in.
closesodoo/odoo#102115
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Hides the empty label the same way as the group-by field if it doesn't
need to be shown (no default_location_dest_id/default_location_src_id).
Part of task-2985735
closesodoo/odoo#102759
X-original-commit: 6030147e12b628e8759700058b8ac3c3889007a8
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
This PR adapts the form views since the merge of #100570.
task-3002465
closesodoo/odoo#102750
X-original-commit: 03b7ed51d9bb1e0717d21cd6516f98e477a2c926
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Instead of looking to all partners inside the database, only filter on the ones that are used by accounting operations.
X-original-commit: ce0a37386f03b24f9730b8a05ea45abf6347dc0b
Part-of: odoo/odoo#102733
The full syntax should make use of eval="..." directly in XML. Doing this leads to the fact the formulas, when displayed in the UI, don't contain any call to ref(), but directly the ids obtained from these calls.
Before this commit, the shortcut syntax used to declare the same expressions did not work in the same way and kept an explicit ref() in the formula to evaluate. We now do the same in both places.
We don't want to support explicit ref() in formulas (a user modifying a formula will anyway not know the xmlid to call). The enterprise part of this PR takes care of that.
closesodoo/odoo#102718
X-original-commit: ea291e4d1dea374455cd8a15bf84662278f4a750
Related: odoo/enterprise#32542
Signed-off-by: Laurent Smet <las@odoo.com>
When selecting the "Add to batch" wizard, if a user selected "Add to an
existing batch transfer", the only batches appearing there would be only
draft batches, while it could be added to in_progress batches as well.
It also displayed waves transfers with the batches, so it now only shows
batches.
Also restricted the creation of a batch in the related field since there
is an explicit option to create a new batch transfer.
Somewhat the same for the "Add to wave" wizard as it would display
cancelled waves as well.
Part of task-2985735
closesodoo/odoo#102715
X-original-commit: a8db2c5fe4b2ea1f28c6ea788ac1976678da11aa
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Within Purchase tab:
- Make Quantity hidden by default.
- Move Currency right after Price.
Move Purchase Description to the right of Vendor Bills.
closesodoo/odoo#102702
Task: 3004014
X-original-commit: b3e78b5a8f825650123004a8b8677aaacfe6b43e
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Jean-François Aubert <ajf@odoo.com>
Before this commit, when the day of the month was smaller than 10,
multiple days were highlighted as today on the datepicker.
Now, only the correct day is highlighted.
closesodoo/odoo#102296
X-original-commit: 0545178d5d09f659d5309069ebcae9d7162356a0
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
This commit allows to regenerate the connectors of the step block when
one of the columns of the block is duplicated or deleted.
Steps to reproduce the fixed bug:
- Drop a steps block
- Duplicate one of the columns
=> The last column of the first row has a connector to the right of the
page.
closesodoo/odoo#102797
X-original-commit: 56522f4a26c95878bb726f54eb02c8c948576875
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit the neutralize system introduced in v16 was using ORM
methods in order to change appropriate records. Although flexible, this approach
could lead to call some methods with side effects while neutralizing
(eg: overloads of write).
This patch converts the neutralize system to a safer "inert" SQL based approach
by migrating the generic method _neutralize to SQL files exposed in the
data folder.
Task id: 2961687closesodoo/odoo#102792
X-original-commit: e5dbded9bb363351feff7ca8a56c7f8a6860f492
Related: odoo/enterprise#32580
Signed-off-by: Fabien Meghazi <fme@odoo.com>
For the "+New" button, a `get_modules_info` route was added because the
information cannot be built-in the page by a server-side QWeb template
anymore.
This commit removes this route and replaces it by a call to the default
`search_read`.
task-2687506
closesodoo/odoo#102791
X-original-commit: 7f83e398b68d7c7544753e2b8bb1b334fb5f7036
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Only kanban, tree and form implements onchanges.
Therefore, on calendar, graph, pivot, ..., putting `on_change="1"`
is useless and is a waste of resources and KB.
e.g. CRM lead pivot view
Before:
```xml
<pivot string="Pipeline Analysis" sample="1">
<field name="create_date" interval="month" type="row"/>
<field name="stage_id" type="col" on_change="1"/>
<field name="expected_revenue" type="measure"/>
<field name="color" modifiers="{"invisible": true}"/>
<field name="automated_probability" modifiers="{"invisible": true}"/>
<field name="message_bounce" modifiers="{"invisible": true}"/>
<field name="probability" on_change="1" modifiers="{"invisible": true}"/>
</pivot>
```
After:
```xml
<pivot string="Pipeline Analysis" sample="1">
<field name="create_date" interval="month" type="row"/>
<field name="stage_id" type="col"/>
<field name="expected_revenue" type="measure"/>
<field name="color" modifiers="{"invisible": true}"/>
<field name="automated_probability" modifiers="{"invisible": true}"/>
<field name="message_bounce" modifiers="{"invisible": true}"/>
<field name="probability" modifiers="{"invisible": true}"/>
</pivot>
```
I would have like something smarter, like using the `editable` concept
for instance, but it's not that easy.
e.g. kanban is not considered as editable, while it does support
onchanges when grouping record by a field and drag and dropping
record from one column to another.
However, if we change the kanban view to make it editable,
the view validation will start validating the fields domain:
https://github.com/odoo/odoo/blob/45d4ac14f65c53dcde56592715d50169bde116ad/odoo/addons/base/models/ir_ui_view.py#L1439-L1442
causing issues:
- If a field used in the domain is not in the view, it will need to be
added in the view,
- while it will not be used, as you cannot do a search in related fields
in kanban views anyway.
e.g.
```
odoo.tools.convert.ParseError: while parsing /data/build/odoo/addons/analytic/views/analytic_line_views.xml:120
Error while validating view near:
<kanban class="o_kanban_mobile" __validate__="1">
<field name="date"/>
<field name="name"/>
Field 'company_id' used in domain of field 'account_id' ([('company_id', 'in', [company_id, False])]) must be present in view but is missing.
```
In addition, the kanban doesn't need the readonly and required
attributes on the field nodes, as other editable views (tree and forms)
do.
In addition, the tree list is currently considered as "editable" only
when it has `editable="bottom" or `editable="top"`, while
a tree without this editable attribute can still trigger onchange,
for instance when using `widget="handle"` or `widget="boolean_toggle"`.
We should therefore making the tree list editable whatever the case,
leading to the same issues than listed for the kanban above,
or make an exception for field in non-editable tree views using a
widget..
So, as the smarter way seems difficult and risky, for a limited gain
I choose the easy way by separating the concept "editable" and
"onchange-able" and to not set `on_change="1"` on views not considered
as "onchange-able".
closesodoo/odoo#102788
X-original-commit: aeb65ee536b1611c1cb829c91906f327f8e331c7
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
You cannot set a receivable or payable account as a bank account of
a bank journal directly, but it is very possible to just set an
account of another type, then change the type of this account to
receivable.
This new constrains will make sure that you cannot change the type of
an account.account set as bank account on a bank journal to any of those
two types.
closesodoo/odoo#102790
X-original-commit: f9500ca4c898cd86681cc2e48ec2c66cf5670917
Related: odoo/enterprise#32579
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: Nicolas Viseur <vin@odoo.com>
The resequence form view css has been broken, this aims to restore
it as it was in previous versions
X-original-commit: aa1fc47cc52b7ae51fb66ba077eb8b2691d0dbff
Part-of: odoo/odoo#102790
Since [1] the community ecommerce dashboard was not rendered anymore.
This is because a `t-name` was combined with a `t-extend`.
This is unsure why but since `t-extend` is deprecated anyway, we replace
it by `t-inherit`.
Note that for some reason, it was then causing an issue in
website_sale_dashboard which inherit from this website_sale template.
The template would not be found anymore.
Indeed, if the inherit mode is extension, a template has to inherit the
base one of the inherit hierarchy and not the one he wants to inherit..
```xml
<!-- module A -->
<template t-name="A.template"/>
<!-- module B -->
<template t-name="B.template" t-inherit="A.template" t-inherit-mode="extension"/>
<!-- module C -->
<template t-name="C.template" t-inherit="A.template" t-inherit-mode="extension"/>
```
This part is adapted in the enterprise related PR.
[1]: https://github.com/odoo/odoo/commit/dcf79f01b33a4f3ddb7e77480f0a7a8be1cd3794
task-2993773
closesodoo/odoo#102782
X-original-commit: 85905934c2ad2507cfc6f74428db61ac97a3bc41
Related: odoo/enterprise#32578
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit includes several changes in the Plausible dashboard:
- Remove the "Analytics" title.
- Add margins (container-fluid => container).
This also fixes the country map overflow and the flickering.
- Remove the duplicated scrollbars.
- Use the background colors from within the iframe.
- Hide the date range buttons by default, but show them if website_sale
is installed.
It also reorders the Reporting menu as follows:
- Analytics
- eCommerce
- Online Sales
- Visitors
- Page Views
task-2993773
X-original-commit: b8c1976e933628182496929d348dda11b5051a0c
Part-of: odoo/odoo#102782
While working in the current state of the website configuration, the
overlay computation was not working anymore in case the scrollbar is
moved out of the wrapwrap. Indeed, in that case, the position was wrong
by the amount of the page scrolling.
While we could include that scrolling value in the equation, this commit
chooses to restore the way it worked before the "website-in-backend"
merge at [1]: making the overlay be naturally positioned according to
the page scrolling wherever the scrollbar is. To do that, the overlay
had to be moved inside the content (the website iframe) which has the
disadvantage of risking the overlay design being broken by a theme. This
solution was chosen as it simplifies the code, and potentially allows
for performance improvements in the future: not forcing a position
recompute after each scroll (the animation should already be smoother /
more performant this way). This will actually be needed for another fix
/ improvement: the background image overlay has to be in the iframe too.
Note: a further commit will move back the scrollbar behavior out of the
`#wrapwrap`, this is thus especially needed.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3bclosesodoo/odoo#102785
X-original-commit: 872bb20b3ac08cf82613e15e6634a2e7593ccf7a
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since BS5, the <html> receive the 'smooth' CSS value for the
'scroll-behavior' property. As the name indicates, it makes scrolling
smooth (on click on anchor link for example) instead of an instant
jump (although the exact behavior is left to the browser).
The problem is that this auto-smooth from the browser conflicts with
the "smooth drag and drop" code (at least if the scrolling target is
actually the `<html>` element which is never the case currently). Indeed
this code expects to make small instant jump depending on the position
of the user cursor. This commit solves the problem by disabling the
browser auto smooth for the duration of the drag and drop.
Note: a further commit will move back the scrollbar behavior out of the
`#wrapwrap`, this is thus especially needed.
Note: this bug fix could be back-ported, should the need arise (custo
might want to use the 'smooth' 'scroll-behavior' in stable without BS5).
Although the only side effect is slower smooth drag and drop.
X-original-commit: 81ed9bee81bacca7b55598e9af7cac51cd7805cf
Part-of: odoo/odoo#102785
The smooth drag and drop in edit mode (over the website iframe)
currently works correctly. This would not be the case if the scroll was
not on the `#wrapwrap` but left to the `<html>` element. Indeed, special
code handles that case, but that code is actually not needed in case
what is being dragged is outside an iframe and that the smooth
scrolling is performed inside that iframe.
Note: a further commit will move back the scrollbar behavior out of the
`#wrapwrap`, this is thus especially needed.
X-original-commit: 4947ef118c646171fd3358135dcab8f63efa04d2
Part-of: odoo/odoo#102785
An option to edit tables via a specialized overlay was made with [1] for
the backend edition of HTML fields. It was indirectly added for the
website builder where an UI to do that already exists (in the editor
panel). It is actually a problem because of the way it was implemented:
- Rely on the fact this is not the `<html>` which scrolls (which cannot
be considered necessarily true and won't be true by default in a
future update).
- Use 'visibility' property instead of 'display' to hide the UI making
the UI participate in the rendering of the page at all times (and when
the `<html>` scrolls actually shows a white bar at the bottom of the
website page).
It was decided we do not want this UI on the website side. This commit
takes the easy road: just force the fact it is hidden. Indeed, not
instantiating it comes with a bunch of problems as the related code is
spread throughout the editor code. A better implementation will follow.
Note: a further commit will move back the scrollbar behavior out of the
`#wrapwrap`, this is thus especially needed.
[1]: https://github.com/odoo/odoo/commit/7a64a04421171469c58bb94bbe8c55b1e2fdf3f2
X-original-commit: 8c1a719674315eadb6d8f6c925cc4303227fad67
Part-of: odoo/odoo#102785
The `scrollTo` method and related utils (jQuery animate, ...) were not
properly adapted to work in the context of multiple documents. E.g. the
website editor code (outside the website iframe) is calling the
`scrollTo` util to scroll to added snippet elements (inside the website
iframe). In that case, the util was performing some searches in the DOM
outside of the website iframe while it was meant to be done inside. The
result was that the scroll was not considering the website fixed navbar
and scrolled "too far".
Another bug is visible only when the scrollbar is left to be the natural
browser one (not on the `#wrapwrap`). In that case, the `scrollTo` util
simply had no effect anymore as the `animate` override of jQuery was not
adapted.
Note: a further commit will move back the scrollbar behavior out of the
`#wrapwrap`, this is thus especially needed.
X-original-commit: ab417de98068afaaa12995726c7c6445f075ca4f
Part-of: odoo/odoo#102785
Replace some layout magic with some layout determinism; in particular,
the view attempted to have a 4 column layout which is not well supported
in grid form views.
This commit instead create a "normal" structure (outer group > inner
group) for "boolean" group access (e.g. 'Extra Rights' or 'Technical'
sections of the user form access groups, whilst in debug mode).
closesodoo/odoo#102789
X-original-commit: fd854e87d8a138052302afbd3da486f41102c695
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
The fiscal country field could be used to create a new res country or
open the form view and allow to change things such as the country code.
This is obviously an issue and shouldn't be allowed.
closesodoo/odoo#102708
X-original-commit: 0881199fba43e01d6d7613eff00549eac5827480
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: Nicolas Viseur <vin@odoo.com>
The invoices and sale orders got a button "Preview" to reach their
frontend/website page. One of the goal is to then be able to enter edit
mode and customize it.
But since we merged frontend > backend with [1] (and multiple iterations
since then), landing on the frontend is not a good idea to do that as
you would then need to click on the "Editor" button to go back to the
backend and be able to enter edit mode. Now we reach the iframe preview
directly.
Note: this will be improved in a further update to not require a reload
of the backend when clicking on the button.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3bclosesodoo/odoo#102787
X-original-commit: 007ae49e9c94061adf34aa9f911c7a9a0e873e0e
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
The quotation templates got a button to design them, which lands on
their website/frontend preview.
The goal is to then be able to enter edit mode and customize it.
But since we merged frontend > backend with [1] (and multiple iterations
since then), landing on the frontend is not a good idea to do that as
you would then need to click on the "Editor" button to go back to the
backend and be able to enter edit mode. Now we reach the iframe preview
directly.
Note: this will be improved in a further update to not require a reload
of the backend when clicking on the button.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
X-original-commit: a98ea96b52f6ccfd43e364720001ed4c4bcbcb4e
Part-of: odoo/odoo#102787
Pierre Rousseau