Since [1] the back button did not navigate within the steps of the
website configurator anymore.
After this commit the window location change that happens within the
browser is copied back into the state - thus causing a redraw of the
correct configurator step.
Steps to reproduce:
- Create a new website
- Go to second step
- Press browser's Back button
=> Did not navigate to previous configurator step.
[1]: https://github.com/odoo/odoo/commit/56cc3dfab156f21c7ef97b3c407f1480b094fe93
task-2789075
closesodoo/odoo#96766
X-original-commit: d32f8a9d64f0487e1e61ec7cee7cffde21b8ddb2
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since this commit [1], when you select the Header position option and
set it to "Over The Content", the change is not saved if you did not
edit something else in the page too.
Indeed, now that the "save" works correctly (and that it no longer saves
the page every time). It does not detect the change made by this option
which is to add a class on the '#wrapwrap' element. (The editor looks
for changes inside the wrapwrap but not on it).
This commit checks if any page option is dirty on save on top of
checking if the content of the page has been modified.
Additionally, this commit fixes a bug that would occur on Firefox based
browsers where the hidden input used to display the status of these
options would be auto-completed by the browser in some conditions.
(https://bugzilla.mozilla.org/show_bug.cgi?id=520561).
This could result in an incorrect state being displayed.
To reproduce:
- Change the option, click on cancel, start the editor
- the incorrect state is displayed
A test is also added by this commit to verify that all the page options
works correctly.
[1]: https://github.com/odoo/odoo/commit/bab673488e185ddd7792aedecc3870663290fed3
task-2871426
X-original-commit: ea7a69b344d970cc2b31555f4cd8fd7c5e2fc6d2
Part-of: odoo/odoo#94949
==== Short version ====
Google is deprecating Universal Analytics in July 2023 and Google
Sign-In in March 2023. Google Analytics Embed API is based on Sign-In,
meaning it won't work anymore. It actually already doesn't work anymore
for accounts created somewhere after mid-2020 apparently.
There is no plan for now for Google to allow Analytics 4 dashboard to be
embed in external website.
We therefore can't do anything to keep the Google Analytics dashboard in
Odoo.
In previous stable version, it was kept but is displaying a warning
about it (as until mid 2023 old accounts can still embed it).
All this is about the embed dashboard, not the tracking in itself for
which Odoo is already adapted in Odoo 15.0 for Analytics 4.
==== Detailed version (following short version, read it first) ====
- Universal Analytics EOL July 2023, see [1].
- It will be replaced by Analytics 4 for which Odoo is already ready and
actually using it since version 15.0 with [2].
- Google Sign-In EOL March 2023, see [3]. Analytics Embed API was based
on it, it won't work anymore.
- There is no plan (for now) for Google to allow Analytics 4 to be able
to be embed in external websites. They seem to just have dropped the
"feature".
This was confirmed by Google here [4] and indirectly here [5] in the
DOC:
`Note: This API does not support Google Analytics 4 (GA4) properties`
- While the EOL is planed for 2023, the dashboard integration is already
not working anymore for new accounts.
- Old projects/keys/accounts can still embed their analytics dashboard.
The threshold seems to be somewhere mid-2020, according to [6].
It seems to be accurate as my own key from 2018 still works, while my
keys from 2021 do not.
==== Fix ====
- In stable, warn user about it in their Odoo Analytics dashboard (this
PR) and also add a warning about that on the doc.
- In master, simply drop the whole google analytics dashboard
integration and remove the doc about it, see [7].
==== Useful links ====
[1]: https://support.google.com/analytics/answer/11583528?hl=en
[2]: https://github.com/odoo/odoo/commit/78bc86cbeccfc5df16218aee2b0d7c501e5c05b5
[3]: https://developers.googleblog.com/2022/03/gis-jsweb-authz-migration.html
[4]: https://issuetracker.google.com/issues/233738709?pli=1
[5]: https://developers.google.com/analytics/devguides/reporting/embed/v1
[6]: https://support.google.com/analytics/answer/11583832
[7]: https://www.odoo.com/documentation/15.0/applications/websites/website/optimize/google_analytics_dashboard.html
Finally, note that it means that from July 2023 to Octobre 2023, while
Odoo 14.0 is still supported, Google Analytics won't work anymore in
that version as it will still be designed for Universal Analytics and
not Analytics 4.
opw-2710910
opw-2855405
opw-2881515
opw-2892370
task-2790245
task-2820890
closesodoo/odoo#96280
X-original-commit: d065595f77790fb5ab9480f6de5b88549352324b
Related: odoo/enterprise#29666
Related: odoo/upgrade#3698
Related: odoo/documentation#2499
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
The new list and form views were merged recently [1], but they
weren't activated because they weren't 100% ready yet. This is now
the case. This commit adds those views to the view registry. As a
consequence, a lot of qunit tests and tours needed to be adapted,
mostly for selector changes.
We also add legacy list and form views to the view registry, with
keys 'legacy_list' and 'legacy_form'. This allows to force those
legacy views when necessary. For instance, we did it in views
using complex custom legacy x2many field widgets that haven't been
converted yet (we have a compatibility layer but it isn't complete
and doesn't support every advanced usecases).
[1] odoo/odoo#92475
Part-of: odoo/odoo#78221
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
Co-authored-by: Géry Debongnie <ged@odoo.com>
Co-authored-by: Samuel Degueldre <sad@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Simon Genin (ges) <ges@odoo.com>
Co-authored-by: Francois (fge) <fge@odoo.com>
Co-authored-by: Michael Mattiello (mcm) <mcm@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Lucas Perais (lpe) <lpe@odoo.com>
Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com>
Co-authored-by: luvi <luvi@odoo.com>
Before this commit, the tours default_shape_gets_palette_colors and
edit_link_popover were not using the tour utils function
registerEditionTour, that starts a tour on the iframe, in edit mode,
with a timeout on the first step.
Because this timeout was not there, loading the iframe and the snippets
menu could take longer than the default timeout and the test would fail
inconsistently.
task-2687506
closesodoo/odoo#96164
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit aims at making the website dialog as well as the edit_menus
tour more stable.
Commit [1] introduced a new dialog API for website.
The component WebsiteDialog handles click asynchronously.
Prior to this commit, the tour could sometimes detect and click on modal
triggers before the actions that the previous trigger was triggering
could complete. This could lead to a modal closing too early either
because a click would done on the wrong modal or the input was completed
before the validation method was called (since the click handlers are
asynchronous).
Here are a few examples of possible failure in the tour :
- The tour clicks on "Add Menu Item", which should open a new modal
- The tour then clicks on OK to make sure the modal does not close.
- The click on OK is done before the New Menu Item modal is open and
therefore is triggered on the previous modal
- The modal is closed too early
- The tour clicks on OK while the URL field is empty
- Before the validation method is processed the tour inserts a value in
the input field.
- The validation method doesn't block the OK method which results in the
dialog being closed
- The tour expects the dialog to be open and crashes
- The tour clicks on OK while the URL field is empty
- Before the validation method is processed the tour inserts a value in
the input field
- The tour clicks on OK again
- 2 entries are created instead of one.
The last one doesn't crash the tour but is still incorrect.
This commit disables the buttons when they're clicked for the first time
until the handler is processed.
This commit also make the triggers in the tour more specific so that the
tour always clicks on the right modals.
[1]: https://github.com/odoo/odoo/commit/28a78fb4e4e4465aa99fb94f7cac3a21b2188502
runbot-4122
closesodoo/odoo#95839
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since frontend to backend commit [1], links having `enable_editor=1` to
enable edit mode were not working anymore in certain cases.
Case 1 [OK]*:
From frontend, click on `enable_editor=1` link without `/@/` in it.
Case 2 [OK]:
From frontend, click on `enable_editor=1` link with `/@/` in it.
Case 3 [KO]*:
From backend, click on `enable_editor=1` link without `/@/` in it.
Case 4 [KO]:
From backend, click on `enable_editor=1` link with `/@/` in it.
This commit fixes case 4 and adds a test for all cases, while leaving
case 3 commented as it will be fixed later with a larger fix related to
URL change listener.
* Note that we will probably change the behavior for case 1 and 3: if
the version with /@/ + enable_editor=1 enters edit mode properly in
both frontend and backend contexts (case 2 and 4), it's probably not
worth having code to support case 1 and 3.
The issue for case 4 was that it was trying to load the whole Odoo app
inside of website preview iframe instead of making the parent window
load that URL.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3bclosesodoo/odoo#96054
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: test_website_modules
This commit restores the display of the website loader (the "Building
your website" GIF) during the installation of a module from the new
content modal, or after completing the configurator flow.
Follows the merge of the "website in backend" task at [1].
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
Part-of: odoo/odoo#81485
Before this commit, switching languages from the language dropdown while
in edit/translate mode was broken.
Now, the click event on this dropdown is listened alongside links with
external redirection from the WebsitePreview client action, so that the
client action leaves the edit mode while frontend is redirected to the
right language.
For that, a new leaveEditMode method is added to the website service,
which removes the edition classes and unmounts the Editor component.
This will further be reviewed in future commits.
Also, adding a new language from the language switcher dropdown directly
opens the wizard in a dialog on top of the WebsitePreview client action.
Follows the merge of the "website in backend" task at [1].
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
Part-of: odoo/odoo#81485
Issue introduced by commit b0a2a41
The template's "flags" value was not in the t-nocache values to use when
rendering languages.
X-original-commit: 7827d2dbc1fbef3cc0dc898baa0af30ed1f23fca
Part-of: odoo/odoo#95222
Introduced with [1] the goal of this tour was to check some lazy loading
stuff regarding the edit mode.
It was then "wrongly" adapted with [2] where the tour actually still
started in the frontend and then clicked on a the new UI button (top
left floating icon of the frontend > backend task) to indirectly enter
edit mode.
While it was working, that's not what the test was aiming to test. The
test should remain as it was, testing the edit mode. While the edit btn
is now in the backend and not the frontend, the tour should just start
there.
Note that this commit is required as the behavior the tour was now
relying on is removed by the previous commit: the Edit button is not
entering edit mode anymore.
Instead of adding a new step to click on the Edit btn, let's just start
the tour as before on the step where you can click on Edit.
It will make the test less dependent of other behavior. This is
especially true since that frontend "Edit" button will most likely
change again or be removed (and introduced back?). We don't want the
tour to rely on this.
If those new UI button need to be tested, it should be in another test.
[1]: https://github.com/odoo/odoo/commit/6f4c60fe1bb6e460ec6da00c59a9825271893729
[2]: https://github.com/odoo/odoo/commit/99b50d18e220aedf14de806f4bf1b2d35c32de35closesodoo/odoo#95002
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit fixes an inconsistent behaviour in tours using the website's
"Edit Menu" dialogs.
When adding a mega menu, two dialogs are displayed:
- The main "Edit Menu" dialog, from which you can open
- The "Menu" dialog with the mega menu label input
When these two dialogs were opened, and closed successively (click on
"Ok" to confirm the menu label, then click on "Save" to save the new
website menu), the tour was sometimes triggering the primary button of
the wrong dialog.
Two issues were leading to this inconsistent behaviour:
1/ Sometimes, the tour would click twice on the same primary button,
and would not wait for the current dialog to close.
To prevent that, extra_triggers are added to the steps to check that the
first click was correctly taken into account (and so, that the upper
dialog, that was the active dialog, was closed).
2/ Other times, the tour would click on the wrong dialog primary button
(it would click on the inactive dialog's button that would save the menu
without validating the label first).
This was coming from the web_tour.TourManager inaccurate
$modal_displayed property, which was defined and used in two different
javascript threads of execution. It could reference modals that were
not the actual modals from the DOM, when used in _check_for_tooltip.
To prevent that, that property is set inside the method it is used in.
It could be defined as a const and not a property, but this way the
commit history is left untouched.
runbot-4000
runbot-4001
runbot-4004
runbot-4005
closesodoo/odoo#94924
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Commit [1] moved the edition of the website in the backend and
introduced an iframe as the editable. In doing so, some tour
actions became unstable.
The issue is that previously, when an action reloaded the page, the tour
service would reload as well. This is no longer the case and the tour
service stays active when the page is reloaded (e.g. when saving a
page). This can lead to a tour clicking on an item before it is ready to
be clicked.
Specifically in this case, the tour saved and clicked on edit as the
next step.
Clicking on edit before the page is properly reloaded leads to the click
being ignored.
This commit uses the util function `clickOnSave` which ensures we're out
of edit mode and the page is reloaded before doing anything else.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
runbot-4074
closesodoo/odoo#94932
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
The drag and drop mega test is quite simple: the python gets the list of
all the snippets (by rendering a view + etree), then it just starts a JS
tour by passing all those snippets in the tour URL.
From there, the JS tour is in charged of building its own steps based on
the list of snippets it received from the python.
The MOST important part is to be 100% sure that the built steps are as
expected: ~5 steps / snippets: ~220 steps with website only and ~280
steps with all modules.
If we don't have that check, the tour could suddenly not test anything
because the step list would be empty, but the test wouldn't fail.
Thus, we don't want to programmatically try to compute that step amount
but want it to remain an hardcoded number, which is lowered in this
commit as if we have 220 (it could be 200, 150..) steps, it means that
the steps were built as expected.
Note that since the test is run on post_install, 280 was fine since all
modules were installed.
But the nightly build is also testing this test with only the website
module, ultimately failing.
Note that this check was actually not working at all since [1] as there
was a typo on `length`.
[1]: https://github.com/odoo/odoo/commit/61b19dafd1fb79120f701b94038bbe859aa2e271closesodoo/odoo#94614
X-original-commit: 23c6b49ba43e6146143bf83bdfd7ce93934961ea
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
By starting the get_switchable_related_views request when the
WysiwygAdapter is started, and awaiting it only when we need to know,
we can improve the initial loading time of the editor.
See merge commit for more information.
task-2687506
When clicking on save while having a popup open, in some conditions,
a traceback can appear due to a race condtion.
This is caused by an event listener which updates the visibility status
of said popup in the editor panel. When saving the popup is closed,
and the cleanForSave starts, but while the popup is closing an event
is triggered which recreates editors (_onSnippetOptionVisibilityUpdate).
This commit aims at mitigating the appearance of this race condition
by listening to the .hide event instead of the .hidden, which means
the event is fired right away instead of 400ms later.
See merge commit for more information.
task-2687506
This commit mocks the website service for all the QUnit tests.
As the website module now defines a patch on the WebClient and NavBar
components, adding the website service, this service needs to be mocked
for all the tests. This is done by patching the QUnit.testStart hook.
Also, after the addition of the new media dialog, this component is
mocked at the field html unit test.
See merge commit for more information.
task-2687506
*: website, website_blog, website_crm, website_event, website_forum,
website_hr_recruitment, website_mass_mailing, website_sale,
website_sale_loyalty, website_slides
This commit adds the current website displayed view xmlid outside of the
iframe, on its container, so that the tours registered with
registerThemeHomepageTour can continue to prepend their triggers with
the view xml id.
Introduce registerEditionTour: this function will allow tour maker to
more easily register a tour that needs to start in the iframe's backend
and go in edit mode.
See merge commit for more information.
task-2687506
Co-authored-by: Benjamin Vray <bvr@odoo.com>
Co-authored-by: Younn Olivier <yol@odoo.com>
The test was introduced in [1] with a typo on the first step (which is
only there to ensure the test does contain steps).
Note: with the 15.1 forward-port, the "number of steps" check had to be
adapted because snippets were removed at [2]. This reveals however two
issues:
- Snippets which use the generic "Dynamic Snippet" as base are not
tested by the test.
- [2] removed the s_speaker_bio snippet by mistake
Both those problems will be fixed in other PR alongside improving the
way the "number of steps" check works.
[1]: https://github.com/odoo/odoo/commit/460d5ecb926c13a79ba363f8f86442433d91bf6f
[2]: https://github.com/odoo/odoo/commit/b5c87d86cad1aa2b44f805da0b2d6635aeb85b96closesodoo/odoo#94359
X-original-commit: 8e6a6ab532637ef9ef8d87ca4062e26b2852825a
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: website, test_website
Since [1], a race condition seems to have become more dominant. It is
actually due to a tour not properly awaiting the editor to be loaded
before using it.
This commit fixes all occurrences of such 'trigger' selectors, even in
tours were it could actually be not a problem. That will prevent devs to
copy paste the problematic trigger.
[1]: https://github.com/odoo/odoo/commit/57793ff912ac5aab8f3d3e014992965d06290bf0closesodoo/odoo#94000
X-original-commit: 38f3a94263b9cf48e9f5a8de553b8602310bcddd
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Somehow the already translated term `Save` in french was translated
again from `Sauvegarder` to `Sauver`.
We already faced that issue when forward porting the tour as that
translation was not the same between versions, see [1].
The tour should be adapted to create a new fake language and some
translations for it (the ones being checked in the tour) to make it more
robust and not impacted by the real translation from transifex.
It would also makes the test faster as it wouldn't have to load a real
language which has a lot of translations.
As this is blocking and preventing any r+ in saas-15.3 a day before the
saas-15.4 freeze/release, this quick fix is introduced in the meantime.
[1]: https://github.com/odoo/odoo/pull/84528#issuecomment-1041323974closesodoo/odoo#92938
X-original-commit: 594ac2c9651f27cc1623fcd5b916cb191241651b
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Could not actually reproduce problem locally.
Looking at the logs, the randomly failing tests seem to be related to
the effects of some previous steps not having been applied even though
the test did proceed further.
This commit introduces intermediary checks to make sure that the effect
of each step is fully applied before proceeding to the next one.
runbot-3171
runbot-3172
runbot-3629
runbot-3630
runbot-3778
runbot-3779
runbot-3859
runbot-3860
closesodoo/odoo#92816
X-original-commit: 2d47b78e677f5046214cb2c8613eeb510753076d
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
When the user selects across several blocks, the link tools are supposed
to be hidden. This was however broken due to other mechanisms restoring
it after it got hidden.
task-2856858
Part-of: odoo/odoo#91314
This is an attempt at fixing a runbot "race" condition.
A first attempt was done in [1] but the selector introduced to make
sure the page was reloaded after the assets were changed was wrong.
This commit fixes that selector.
During the investigation of the problem, it was also discovered that the
SCSS change could take quite a long time on a busy server becasue it
triggers the SCSS compilation each time.
To reproduce that problem locally, run the `stress` command while
executing the `test_html_editor_scss` test.
E.g.:
```sh
$ stress --cpu 32 --timeout 120
```
The error that shows up in that case is misleading because it makes it
look like the confirmation popup was not clicked on.
What is actually happening is the following:
- the Reset button is clicked on
=> the confirmation popup is shown
- the confirmation is clicked
=> the popup is closed and the RPC call is made
- the RPC does not respond within the tour step's timeout
=> the last step is not shown as succesful and the screenshot shows the
non-reset state since the server response did not arrive yet
To be safe on busy servers this commit also increases the timeouts
related to steps that follow updates of SCSS files so that they can be
recompiled on time.
[1]: https://github.com/odoo/odoo/commit/b35f127c86c1d271a76dae7186a96190e8558c73
runbot-3744
closesodoo/odoo#91725
X-original-commit: e04c4f06086ff4287ef4acfc65d5b3d957396ae7
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Configuring the email_to field on the contact us page was not working
anymore. The email was always sent to the company email whatever the
user chooses in edit mode. This was due to [1] which gave the priority
to the data-for and prefill system over default values. While this makes
sense in general (e.g. if the URL on the contact us page contains
?name=John, then the form is prefill with "John" whatever the value that
is set as default), it does not make sense for the email_to field which
is always prefilled with the company email.
The data-for/prefill system priority probably has to be reviewed in the
future. Meanwhile, this commit will make the email_to field as an
exception for this system and only use the data-for value if nothing
has been configured by the user.
This commit also handles another case. Indeed "if nothing has been
configured by the users" is currently kinda broken as just clicking on
the form and saving will force the value "info@yourcompany.example.com"
as the email_to value... thus making the form use it instead of the
company email. We will make that as an exception of the exception: use
the data-for value (company email) if what was configured by the user is
the dummy default value "info@yourcompany.example.com".
A test for each of those two exceptions has been added (only the first
test breaks before this commit as [1] made the second test pass by
chance).
[1]: https://github.com/odoo/odoo/commit/7b23d3aacd22f87cb0c22ecd0478eba4a17b4bf3
opw-2842211
Original idea for the first exception:
closesodoo/odoo#91407
X-original-commit: a08574a04ff2ce8ea2d6fd2b79f56cc57bba953b
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: Ivan Yelizariev <iel@odoo.com>
There is some classes that are technical and should not create steps.
Otherwise it compromise the ability to undo/redo or compromise the
ability to detect the dirty elements properly.
This commit prevent thoses classes additions and removals to create
history steps.
task-2836351
closes odoo/odoo#91074
Forward-port-of: #90064
X-original-commit: 41d8a0f246a134e2b5292da4db11e67aa9cfb4ed
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, the modifications of the form were not saved if the
user had only clicked on the submit button of the form. Only elements
with the class o_dirty are saved, but since this commit [1], the
observer that adds this class was disabled. The resolution of the bug is
just to remove the fact that the link tool disables the observer that
adds the o_dirty class. This commit also adds a test to make sure that
this bug does not happen again.
Here are the steps to see the bug:
- Go to /contactus page
- Click on edit
- Click on the Submit button
- Change a Form option (eg: Recipient Email, Labels Width, URL, ...)
- Save
Edit again the see that the changes are not saved
[1]: https://github.com/odoo/odoo/commit/c29fe9fa8fc8ff4a5e6f042607ef9b3070d1d339
task-2812722
Forward-port-of: #90064
X-original-commit: 3b45ef633adbeebee4819c30808680644b85c5fc
Part-of: odoo/odoo#91074
This is an attempt at fixing a runbot race condition.
It was executed succesfully without any error on Multi build around
200 times on runbot.
Since [1] the reset button could be clicked before the HTML editor was
reloaded.
The `MutationObserver` in `tour_service.js` is debounced. Because of
this the states used to detect tour steps triggers might differ between
executions.
With the Reset button of the HTML editor not being hidden in the
rendered template, it might be detected before it gets hidden during
the `start` of `ace.js`.
This commit makes sure the the editor is both closed then reopened with
the Reset button visible before clicking on it, and also makes sure the
Reset button is not visible by default upon rendering.
[1]: https://github.com/odoo/odoo/commit/d20468c3463927a54c34688769a22b3949c5c465
runbot-3674
closesodoo/odoo#90453
X-original-commit: b35f127c86c1d271a76dae7186a96190e8558c73
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before this commit, some editor options could break the autocompletion
of form fields. This commit ensures that auto-fillable fields remain
auto-fillable when using the editor. In addition, this commit improves a
test to ensure that this bug does not reappear.
Steps to reproduce the fixed issue:
- Go to the "contact us" page or drop a form in a page
- Edit an auto-fillable field of the form ("Your Name" for example)
- Change the label position of the field
- Save
-> The field is no longer auto-fillable.
task-2715201
closesodoo/odoo#90103
X-original-commit: 455e0cc58c7fa1e02ebaa19dd2f99d829ca6e302
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit allows to give priority to auto-fill values and to values
coming from a data-for when in addition to one of these values this same
field has a default value. The form's test are also improved so that it
checks for this desired behavior.
task-2715201
X-original-commit: 7b23d3aacd22f87cb0c22ecd0478eba4a17b4bf3
Part-of: odoo/odoo#90103
Some form fields are dynamically filled. As the inputs that hold these
values do not always have a value property, their HTML value attribute
can be modified. Before this commit, the form option had to remove these
values before saving so that these values wouldn't become default values
(see [1]). Sadly this system is problematic and can remove default
values set by the user. This commit ensures that only values from
auto-fillable fields and from data-for fields will be removed and from
now, the suppression of these values is done at a more appropriate time
than what is done in [1]. Test is added with this commit to verify that
the default values are not erased on later form edit.
Step to reproduce the fixed issue:
- Create a form, add a (required hidden) field with a default value
- Save, then enter edit mode again
- Add a new field and save again
The default values of the form are gone. Enter edit mode again to see
the hidden input, you will see there is no value.
[1]: https://github.com/odoo/odoo/commit/b637a5e32f767b62736241042f88fa0cecf9f10b
task-2715201
X-original-commit: 043e1fdf923d2037dd8da128ab99388f0c92e544
Part-of: odoo/odoo#90103
Current behavior:
When an admin user modified a file with the HTML/CSS/JS editor in a
website, users that had "editor and designer" right couldn't access
the HTML/CSS/JS editor anymore.
Steps to reproduce:
- Have user 1 (U1) admin
- Have user 2 (U2) with website access set to "Editor and Designer"
- U1 modify the css user_custom_rules.scss with the HTML/CSS Editor
- U2 can't open the editor of that website because he is not in the
setting groups or the one that created it
opw-2733109
X-original-commit: d20468c3463927a54c34688769a22b3949c5c465
Part-of: odoo/odoo#89211
Co-authored-by: roen-odoo <roen@odoo.com>
Since [1] nested menus were not saved anymore because model ids do not
support `str` anymore.
After this commit the menus update data contain an integer `parent_id`
making them understood again by the model.
The `parent_id`s returned by `nestedSortable()` are the ones obtained
through a regex match, and therefore are strings.
Steps to reproduce:
- go to the 'Home' web page
- click on 'Edit Menu' in the 'Pages' menu
- drag and drop a menu item to nest it (e.g. put 'Contact Us' inside
'Home')
- click on 'Save'
=> nested entry disappeared from the menu instead of being nested under
its parent
[1]: https://github.com/odoo/odoo/commit/534087fa8d3c9947a918aa109f4030b5628a80d1
task-2781260
X-original-commit: d7bfb935580d6cc70dc213657c1a6dbc85dfa756
Part-of: odoo/odoo#89147
Before this commit, this bug was present in edit mode:
- Go into edit mode on an empty page.
- Click on the THEME tab on the right.
- Click on the empty "DRAG BUILDING BLOCKS HERE" area.
- Click on the THEME tab again.
- The content of THEME is empty.
It was because since this commit [1], clicking on an 'oeStructure'
activate the Blocks tab but without updating the options in the tabs.
Another similar bug was present when clicking the style tab and then
clicking on the theme tab.
About the first bug, actually a call of '_updateRightPanelContent' is
already done in '_activateSnippet()' (and the Blocks tab is activate by
default) so we only have to use '_activateSnippet(false)' to activate
the Blocks tab. This commit also remove '_updateRightPanelContent' from
the click event of the Blocks tab where it was not necessary.
For the second bug, we can't do the same fix, because it's not possible
to activate the options tab with only '_activateSnippet(false)' so we
had to combine the two functions.
[1]: https://github.com/odoo/odoo/commit/fbe048c202ff7878984adf26bef0651a45851f0a
task-2794266
closesodoo/odoo#88537
X-original-commit: 52d32e26c34bef10823582ef5c1f840492b73d7a
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit permits to:
- avoid DOM modification when starting options of social_media.
- remove the useless HTML related to the social media block.
- generate all available social networks that are present in the DB for
the social media block.
- delete DB social media if there is no value for it in the DB.
- display an alert banner in edit mode if the block has no link.
- use a shared variable for social media db urls in order to avoid too
much RPC.
- custom links are no longer togglable, only deleteable.
task-2739937
X-original-commit: f243bcbafb9291d94840795951c8fd51cab0cae1
Part-of: odoo/odoo#87933
The bold format is overridden to use inline style on a <span> rather
than a <b>. The other formats (italic, underline, strikethrough)
continued to use the default browser behavior. This harmonizes them.
X-original-commit: ce59bbd1c13d7fd4cc6971b89cc95386d95fcd75
Part-of: odoo/odoo#86930
Purpose
=======
Add "Activate" button when selecting multiple languages, select multiple
languages when clicking on "Add languages" in settings.
Specifications
=============
`lang` variable in `base.language.install` changed from Selection to
Many2many to allow multiple languages being activated at once.
Hide globe icon for language fields from view mode (only visible when
editing). Remove state in base.language.install since it's no longer
need to keep track of the installation step.
Task-2662548
closesodoo/odoo#78287
Related: odoo/upgrade#2921
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Commit [1] introduced an automatic start of edit mode when
selecting a theme but didn't take into account wether the frontend lang
of the user was matching that of the website that is supposed to enter
in edit mode.
Steps to reproduce:
- Create an empty database and install website.
- Add an extra lang on website (e.g FR) and visit the website in that
lang.
- Go in settings an create a new website, skiper the configurator,
select a theme.
- Redirect is with enable_editor but nothing happens.
The editor isn't started if not in the source's lang.
This commit redirect the user to the default_lang of the website
so that editor can always be started. It also introduces a tour
to test out the flow.
[1]: https://github.com/odoo/odoo/commit/f474eac4543712ae5b1c7d614f9eff9367445107
task-2687416
closesodoo/odoo#85058
X-original-commit: 02e08af7278cd66d768fe6a4f23aa17eb816be3c
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
The configurator introduced at [1] uses a frontend controller to
display its content. However this results in inconsistent language
translation as the python code uses the users's language but the
localization services uses the frontend's language when on a frontend
page.
Steps to reproduce:
- Create a database with the only language being french
- Install website
- In the configurator, all the pages will be in french except
"Pages and Features"
With this commit, the language for the configurator will always be
the language of the website it's configuring. A test also make sure
that this is the current behavior.
[1]: https://github.com/odoo/odoo/commit/e8a5af2e28a4724f86783746706cb59175f086bf
task-2687416
closesodoo/odoo#84810
X-original-commit: a0f8fdc65566fafe98dab21f5c2dbab9505c3d5c
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before this commit the target of options and nested options tour steps
could be hidden under an opened palette.
After this commit the tips of options and nested options tour steps
require that no palette is opened.
An 'allowPalette' parameter can be used to remove this condition, for
example if 'changeOption' is used to select an option within the
palette during a test tour.
A step is added to close the color palette - which, while opened,
prevents the next `changeOption` step from being activated.
task-2728994 (was task-2675252)
closesodoo/odoo#84093
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When selecting the text content of a link
the underline and italic commands were not working in Firefox.
We re-implement the Browser command to fix this.
task-2667950
X-original-commit: 52a5b2bb692ab6712d497492f4f2fbef3a9a7874
Part-of: odoo/odoo#83895
website{_*}: website, website_blog, website_sale, website_slides
Before this commit if several steps were referencing the same trigger
(e.g. "+New" button in website) only one was displayed, but all were
consumed when it was clicked.
Because of this the tour steps on "+New" were active even when its menu
was opened.
After this commit only the displayed step gets consumed if the step is
marked as 'consumeVisibleOnly: true'.
It cannot be done implictly on all steps because of [1].
This new marker is set on all steps referencing "+New".
The tour steps on "+New" now also require their menu to not be opened.
[1]: https://github.com/odoo/odoo/commit/5e888f8a6ccf9996b3231db6bf314d045619109e
task-2728994 (was task-2675252)
X-original-commit: 0fa40e37e596798665a098ee999f49749b6012a2
Part-of: odoo/odoo#83692
Those steps were removed with [1] to avoid a indeterminist timeout, but by
doing so that part of the feature was not tested anymore.
Sadly, it was broken by [2] without being noticed for a long period of time.
The error was discovered by fixing multiple lang issues in the website
configurator in master.
Note that by creating a new lang instead of using an existing one will avoid
the timout error that lead to the removal of those steps with [1]. Indeed, as
no .po files will be found for that lang, it won't spend time on processing
those files.
[1]: https://github.com/odoo/odoo/commit/a15c7099a36a3a5b4dca9375b233cbe3fe2a280f
[2]: https://github.com/odoo/odoo/commit/745ef9de97544d5c1a97e03be67e903feca40c2aclosesodoo/odoo#83420
X-original-commit: 0b43f52116fd9a58fb0a123db576d822fd541043
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before this commit, a traceback occured when trying to remove a popup
snippet, only if content inside was clicked on before (base case but
that last part was not covered by our main test which drags and drops +
removes all snippets).
The problem is complex and annoying to solve in stable. The cause is the
combination of [1] and [2]. Indeed, with [2] we solved the snippet
activation flow to ensure the onFocus and onBlur methods are called when
needed... but that new correct implementation relies on the fact that
the number of snippet editor instances does not change for the whole
async operation of activating a snippet. That should naturally be the
case but is not because of [1]: when we remove a snippet we first
trigger a snippet activation then destroy the snippet (and its editor
instance)... but the snippet activation is not awaited at the moment.
Thus making the snippet editor instance be destroyed *during* the
snippet activation flow. Of course a better solution than this commit
must be found but this fixes the traceback with a very minimal change
for the 15.0 stable version while waiting for that miraculous solution.
[1]: https://github.com/odoo/odoo/commit/ae219ec06baf0280c76ae09b1453cc1481eece30
[2]: https://github.com/odoo/odoo/commit/0acc5e784b15d9c963660da3781763448503f33e
task-2735663
closesodoo/odoo#83378
X-original-commit: da7c1b5757a7780897c5736ddecc014a7fb50bdb
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Benoit Socias