When a new user is created from the website, the company id was always
set to the first company of the database even if the website was the one
of another company. This flow has been already fixed if there is the
"Specific User Account" setting activated (see [this other commit]).
This commit fixes the same issue but for every case.

Steps to reproduce the issue:
- Create 2 companies A & B
- For each company, create a website linked to a different URL
- Activate 'Free sign up' for company B
- As a public user, go to website of company B
- Go to 'Sign in > Don't have an account?' and create an account

=> If as an admin you check the company of the created user, it is
company A instead of company B.

[this other commit]: https://github.com/odoo/odoo/commit/77c708c516beb322df37220634e178ba82e894c9



task-3277317

closes odoo/odoo#120475

Signed-off-by: Benoit Socias (bso) <bso@odoo.com>

Steps to reproduce the bug:
- Add an Image Gallery (IG) snippet on the page.
- Add 2 new images in the IG.
- Click on the first image of the IG to load its data.
- Click on the trash button to remove the snippet.
- Bug => The snippet is not removed (an image is removed instead).

When a snippet is removed, the `removeSnippet` function is called. The
problem is that the `call_for_each_child_snippet` will never resolve.
Two mechanisms are of interest to understand why: the first one is the
`updateCurrentSnippetEditorOverlay` function. Its goal is to destroy a
snippet each time its target is not in the DOM anymore. The second
mechanism is specific to the IG snippet: when an image of this snippet
is destroyed, the `slideshow` function goes through the remaining
images to update parameters. To do it, the function uses the
`_replaceContent` function that empties the content of the carousel and
then fills it with new data.

When a snippet is removed, a `SnippetEditor` is created for each
element of it. In the case of the IG, a `SnippetEditor` is created for
each image of the the snippet. Because the first image already has a
`SnippetEditor` (because it has been clicked), the callback of
`call_for_each_child_snippet` is called to remove this image from the
IG snippet. The second mechanism explained before will then be called.
Meanwhile, a `SnippetEditor` will be created for the second image.
However, because the `_replaceContent` function emptied the content of
the carousel, the `updateCurrentSnippetEditorOverlay` function will
destroy the `SnippetEditor` of the second image as its target is not
considered present in the DOM anymore. Unfortunately, the
`call_for_each_child_snippet` still needed this `SnippetEditor` and
will never entirely resolve.

To solve this problem, the `removeSnippet` function is executed inside
a mutex. Because the mutex is also used by
`updateCurrentSnippetEditorOverlay`, we are sure that this function
will not destroy the snippetEditor while the `removeSnippet` is still
running.

task-3147271

closes odoo/odoo#111719

Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>

Before this commit, if a link to a page was not correct because of a
case mismatch, it would simply land on a 404 page.
While it's correct, as URL are case sensitive, it leads to a few bad UX
flow at the admin/editor level:
- Create a link in your page (on a text or a button eg), type an URL
  which does not exists (to create it after) like /Page
- Click on the link/button you just made, you are redirected to /Page
  which display a 404 with the "Create page" option (correct)
- When you click on that button, it will actually create a page with
  /page URL, leading to a mismatch between the URL you created and the
  page URL.
  Your link/button will still lead to a 404 URL as it points to /Page.

Since it's just a fallback when an exact URL match is not found, it
should not break anything and should not have bad impact at any level
(seo/speed etc).
Indeed:
- It's done through a 302 redirect
- `_serve_page()` is already a fallback case, so it will only make
  the `website.redirect` and 404 cases a bit slower due to the extra
  search query.

The only possible scenario seems to be if the user (mind the uppercase):
- Created a /Page page
- Created a redirect from /page to /another-page

In this case, /page won't land on /another-page but on /Page.
This flow seems unlikely and is not actually wrong either way.
At least, it certainly is less important than ensuring a case
insensitive fallback.

Finally, note that another solution would have been to either:
- Force page URL to lower case.
  -> This is not stable friendly, people might be relying on this to
     create pages with different casing:
     `/Batman-VII-The-Dark-Knight-Whatevers`, while not recommended,
     doesn't sounds idiot.
     On top of not being stable friendly, we probably want to keep
     offering this possibility
- Redirect all URLs to lowercase endpoints.
  -> This is obviously not stable and not Odoo's jobs. It should be
     something decided by the sysadmin and done at nginx (etc) level.

task-3110294
opw-3104030

closes odoo/odoo#109812

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

Prior to this commit, adding an anchor using auto-complete would not
properly prefix the url with the URL of the current page.

Steps to reproduce:
- Create a page (e.g. /test), add blocks and create an anchor (e.g.
- Save the page
- Click on "Edit Menu" in "Pages"
- Add a new menu entry
- Type '#' in the URL field and select the anchor
- Save

=> The menu entry is wrongly set as it does not contain the original
page's URL inside the `href` attribute. This means that clicking on the
menu from any other place will not properly redirect to the anchor on
the /test page

On top of that, editing a menu entry that was previously linked to a
page would change the URL of the page with an anchor, making it
impossible to access the page anymore until you change the URL back in
the page manager.

Steps to reproduce:
- Create a new page (e.g. test)
- Add a new menu entry that has this page as its URL
- Save the new menu entry (close the dialogs)
- Re-open the Menu dialog and edit the newly created menu entry
- In the URL field, replace it with the page + an anchor
 (e.g. /test#anchor)
- Save
=> The page's URL is now /test#anchor and is no longer accessible

The is due to the `save` method of the `website.menu` model not
containing code to properly manage adding an anchor to the menu.

This commit fixes that.

opw-3067750

closes odoo/odoo#106882

Signed-off-by: Romain Derie (rde) <rde@odoo.com>

Commit [1] actually "repair" the test theme installation that was
actually not calling `_post_copy()` for the website/themes created
through the `_post_init` hook of the `test_themes` module.
By doing so, the Nano theme now correctly activated the
`footer_language_selector` view, meaning that the tour would fail as
this Nano view would mess up with the tour (that Nano view was returned
on top of the Theme custo view).

Those website standalone tests should really be part of the regular
testing suite and not in the nightly build only:
1. This is getting really annoying to fix it again and again, we
   wouldn't have to do that if it was in the regular testing base as it
   could not be broken. This is a waste of time for no reason, as we
   need to investigate, understand and find a fix.
2. For now it only broke due to no real bug, most of the time it is
   because the test need to be adapted to a theme change or something,
   but one day someone will be able to break the website core mechanisms
   (COW, theme install etc) and this will be problematic.
   Note that if this was to happen, the runbot team will be handling the
   issue and the fix with the people that broke it, as it was promised
   when we discussed about moving those tests in the regular testing
   suite. It was the conscensus for us to accept to leave those tests in
   the nightly only (we didn't really had a choice tho).

[1]: https://github.com/odoo/design-themes/commit/fea847977d8bd4b0c0ddfc7685e3d3dc0933759c



closes odoo/odoo#106026

Signed-off-by: Romain Derie (rde) <rde@odoo.com>

When both a specific inheriting view and a non-specific base view are
written simultaneously, the specific inheriting base view must be
updated even though its id will change during the COW of the base view.

This commit sorts the list of written views in order to first handle the
website-specific ones then the base ones which might change some of the
ids of the already updated view.

Steps to reproduce in 14.0+ (no scenario found in 13.0):
- Create a new website.
- Configure the language selector layout to "Inline".
- Configure the language selector layout to "None".
=> Error notification was displayed and change was not applied.

task-2885882

closes odoo/odoo#96120

X-original-commit: cdd82554
Signed-off-by: Romain Derie (rde) <rde@odoo.com>

Homepage was never considered as canonical due to the trailing /
domain.com/fr/ != domain.com/fr

Now _get_canonical_url_localized for homepage is fixed.

Remove all computation related to canonical that is usless for connected
user. It is mainly used for SEO tools/bots/crawler.

Initially planed for 13.0 with [1] but reverted with [2].

[1]: https://github.com/odoo/odoo/commit/33167b3928c767a08fdc7eedc3e6204aac9cac08
[2]: https://github.com/odoo/odoo/commit/deb23450f18196c7f8d9e819db603fccd407b82a



closes odoo/odoo#93191

Signed-off-by: Romain Derie (rde) <rde@odoo.com>

As we have more and more standalone tests related to the website app, it
has been decided with the runbot team to introduce a unique tag to
easily identify those tests.

The goal is to make the runbot build config easier to manage, without
the need to add the new tag name in the command.
Instead, this build will be fired by finding and testing all the
`website_standalone` tests.
The other tags are kept to easily identify what are the test related to.

Command without this (which need to be edited for each new tag):
```
--standalone cow_views,cow_views_inherit,theme_views,theme_upgrade
```
Now:
```
--standalone website_standalone
```

Part-of: odoo/odoo#91012

It may happen than the routing map is cleared while rendering a qweb
view. For example, if an asset bundle is regenerated, the previous one
is unlinked, which causes a cache clearing.

Previously-generated EndPoint objects aren't found any more in the new
routing map, so `request.endpoint` cannot be used any more after a cache
clearing.

This commit adds hash and comparison magic methods on http.EndPoint so
that EndPoint objects created by a previous routing map generation can
still be used after a cache clearing.

Two tests were added: one to test the comparison and hash methods, and
the other to test them in a real-case rendering.

Commit 80a04f7e fixed this bug too, but introduced another issue
which caused many OPW, so it was quickly reverted by deb23450 along
with its performance improvement 33167b39. This commit replaces
80a04f7e with another way to fix the issue.
A third test has been added in order to avoid reintroducing this other
issue.

By the way, this commit also removes the EndPoint.arguments attribute,
as commit 17f19926 removed all usages of this attribute in Odoo 9.0,
but left this initialization here.

OPW-2834546
OPW-2834549
OPW-2834625

closes odoo/odoo#90745

X-original-commit: 21864908
Signed-off-by: Romain Derie (rde) <rde@odoo.com>

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

closes odoo/odoo#88920

X-original-commit: b0d39dff
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Co-authored-by: roen-odoo <roen@odoo.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.

Commit [2] introduce a `website_edit` action but also didn't take into
account that the frontend lang might not be the source's lang.

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, 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
[2]: https://github.com/odoo/odoo/commit/e0cc28dcee977c4aa0c6a7e4ff6c463ab12e55a2



task-2687416

closes odoo/odoo#83508

Signed-off-by: Romain Derie (rde) <rde@odoo.com>

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/745ef9de97544d5c1a97e03be67e903feca40c2a



closes odoo/odoo#83275

Signed-off-by: Romain Derie (rde) <rde@odoo.com>

Backport of https://github.com/odoo/odoo/commit/f18cd32a936829d8a059db0d259189503ee5317f

Some theme are enabling an header template. When doing so, they also disable
the default header template.
But this is not enough, as the user could have changed that template and it is
not the default one anymore.

Then, updating that theme (UX, CLI, Migration) will raise a traceback.

Step to reproduce:
  - Create a website and install theme avantgarde
  - Enter edit mode and select Magazine header template
  At that point, update the theme, either:
  - Through the UI, on theme switch screen, click on Update
  - Through CLI, just run a `-u theme_avantgarde`
-> A traceback will be raised about an xpath error, as both the magazine header
   template and the hamburger header template are active at the same time. Only
   one template is supposed to be activated.

The issue also impact migration, as migrated website can't be accessed due to
the xpath error on rendering.

Theme being impacted (at least): Avantgarde, Graphene & Nano

Note that when installing one of those themes for the first time on a website,
the error won't occur as `_reset_default_config()` will be called through
`_theme_remove()`.

Note that this fix will ensure the correct template is set (and all others are
disabled), but the scss variable won't be correctly set (as it would be if that
template change was done through the right panel).
This is not that much of a problem (considering what it solves), any later
change from the user through the right panel will solve that mismatch.

Fixes https://github.com/odoo/upgrade/pull/3048
task-2593407
opw-2680866
opw-2685951
opw-2685124
opw-2679040

Part-of: odoo/odoo#82470

The countdown snippet has an end action that can be configured to show a
message when the countdown reaches zero. A button in the editor toggles
a preview of this message. However, a bug currently makes the preview
disappear whenever the snippet's widget is restarted... which occurs by
simply hovering some other options.

To solve the problem, the preview visibility is now controlled by a
separate css class s_countdown_enable_preview overriding d-none. This
way, the preview visibility no longer interacts with the widget's logic
and is no longer affected by the widget restarting.

task-2638366

Part-of: odoo/odoo#76343

The flow has been broken multiple times across the years. Let's add a
test in all stable versions.

For this 14.0 forward-port, the test comes with a fix which restores the
13.0 flow which we tried to change in 14.0... but only ended up broking
it. Indeed, with [1], the 13.0 was fixed. And, with [2], we tried to
simplify the flow... but the explanation given by the commit is just
wrong: the flow was just broken and the simplification that was to be
done in fact practically never occurs. The more the reason to add a
test, proving how the flow is working. The simplification may be done
someday but not sure it is really worth it.

[1]: https://github.com/odoo/odoo/commit/076992bdf099f3a645c9a1ef6df2cdcccbf1c2b2
[2]: https://github.com/odoo/odoo/commit/5c007305c9998ade32c6677cac5552101c3a96af



closes odoo/odoo#79628

X-original-commit: dfb0ce4b
Signed-off-by: Romain Derie (rde) <rde@odoo.com>

A bug currently makes the carousel snippet collapse/disappear when its
active contents are removed. This happens because after the removal,
the carousel no longer has an active item.

The solution that was chosen was to not allow the removal of slides
unless using the dedicated option which is there for that. This solution
has to advantage to also allow users to create empty slides (using a
background image for example) by simply removing the columns inside.

task-2506165

closes odoo/odoo#79340

X-original-commit: 3c194faa
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

A while back, the behavior of this setting was changed from a
related field to a computed as a fix to various issues with: cb9f48d3
The setting's value synchronization with what is displayed on the
setting's page is broken, since its behavior changed with commit:
2ccc7352 . It resets to its default value for the default website when
editing a secondary one and is not only confusing but breaks the
setting in some scenarios.

When changing the auth_signup_uninvited setting, the changes
are correctly reflected and not reset to default upon changing
the website we are currently editing.

task-2612686

closes odoo/odoo#76262

Signed-off-by: Romain Derie (rde) <rde@odoo.com>

Setting a controller URL to a menu which is linked to a page should unset the
m2o relationship to preserve the page URL.

Step to reproduce:
  - Create a page (with a menu) and save, eg: "My Page" (url will be /my-page)
  - Edit that new menu and change the URL to /shop (or any controller)

Issue:
  - The page URL is now /shop, which doesn't have a lot sense if there is a
    controller for that URL.
  - Unpublishing the website.page will unpublish the menu, as a menu needs its
    page to be published in order to be visible.

Note: The flow introduced here is the same as if you choose an URL of an
      already existing page, the menu's page will be unlinked from the menu and
      left with its original URL.

task-2575974

closes odoo/odoo#72593

Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>

Before this commit, the routing map generated and used would be the one from
the website the request is performed, instead of the one from the `fw` website
ID which will be the one we redirect the user to.

This issue was introduced with the routing map by website, be8fc229 and is
restricted to a single case: a publisher using the website switcher, and it
won't happen on next page naviguation/refresh as the `fw` website id will be
the same as the current website's ID. Thus there won't be any routing map
mismatch.

Step to reproduce:
  - Create a page on website 2, set it as homepage
  - Naviguate to website 1 on '/' url
  - Naviguate to website 2 on '/' url
This will raise a werkzeug error about `EndPoint not iterable`.

----- Technical analysis ------

This is the current flow:
1. `_dispatch()` is setting `website_routing` to `get_current_website()` -> 2
2. `_dispatch()` is calling `_match()`
3. `_match()` is calling `routing_map()` with key = `website_routing`, which
   was set to 2 in step 1.
4. `routing_map()` is calling `_generate_routing_rules()` which generate the
   rules based on `website_routing`, which was set to 2 in step 1.
5. `_dispatch()` authenticate the user by calling `_authenticate()`
6. `_dispatch()` is calling `_add_dispatch_parameter()`, where URL param `fw`
   is forced in session, so `get_current_website()` now return the correct
   `website_id` -> 1

The issue: in order to handle the `fw` URL parameter (step 6.), we need to
check the rights to ensure we can allow the website switch.
To check rights, user need to be authenticated (step 5.), which is done after
generating the routing map (2. & 3. & 4.).
The routing map is generated based on the current website (step 1.)

Step 6 depends of steps 5 which depends of steps 2/3/4 which depend of step 1,
but step 1 should depend of step 6, which is an impossible cycle.

closes odoo/odoo#70278

X-original-commit: 878e28f9
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>

instead of using ad-hoc weirds

closes odoo/odoo#66649

X-original-commit: 9a129ca9
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>

As `standalone` tests were introduced in 14.0 (see 0453566a), this commit
adds tests to ensure the `inherit_id` of COW views are correctly updated on
module updates.
This test could not be rewritten in a regular test and merged in 12.0 as module
operation in tests try to be avoided (see 5e7e7b00b7d).

See #64446 for more information about the original fix.

closes odoo/odoo#65841

Signed-off-by: Christophe Simonis <chs@odoo.com>
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>

Before this commit, only whitelisted fields would be updated on cow views
during a module update.
A field would be whitelisted if he had the same value than the original view,
see it as a heuristic to not write on modified fields.

But `inherit_id` is not that simple, even if the cow view has a different value
than its original view, it doesn't mean it was modified by the user, it is just
because of the cow mechanism that assigned a copied view as inherit_id, which
is just a copy ofthe original one.

We can thus consider `inherit_id` as unchanged and whitelist it if the `key` is
the same.

In practice, it means that cow'd views did not receive the `inherit_id` updates
as in commit https://github.com/odoo/odoo/commit/c8577568a1e39f6692889b3e21652fa3b8df06b2#diff-823e5db841dca1798ff1300e243059a4e1c93343598d2be5a1d1dcd1d2d0c273R537
where `portal.my_account_link` had its `inherit_id` changed from
`portal.frontend_layout` to `portal.user_dropdow`, see https://github.com/odoo/upgrade/pull/2059:

Considering a module update changing `inherit_id` of D from A to B, the
following use cases are expected. Without this fix, D' never move:

CASE 1
  A    A'   B                      A    A'   B
  |    |                 =>                 / \
  D    D'                                  D   D'

CASE 2
  A    A'   B    B'               A    A'   B   B'
  |    |                 =>                 |   |
  D    D'                                   D   D'

CASE 3
    A    B                        A    B
   / \                   =>           / \
  D   D'                             D   D'

CASE 4
    A    B    B'                  A    B   B'
   / \                   =>            |   |
  D   D'                               D   D'

Opw: 2422773
Opw: 2422727
Opw: 2422770
Opw: 2423406
Opw: 2423859

X-original-commit: 2951ed681aa5e31563e501de691716806ddb46bd

Previously, when removing all the content of a snippet, that snippet
would get automatically deleted. This was not the case for parallax
snippets because we previously intended the user to drop the parallax
snippet, empty it, and drop other content inside of it.

Recently, we added the parallax option on all snippets, rendering the
previous workflow obsolete. There is now no longer any reason to keep
empty parallax snippets. This commit fixes that.

task-2446008

closes odoo/odoo#64907

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

This test at least ensures that a SCSS edition through the editor can
properly be done and indirectly tests that the assets order is correct
(in prevision of a future asset refactoring).

closes odoo/odoo#64754

Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>

The goal of this commit is to update the default theme
tour (steps, changes on snippets...) as in other themes tours.

The url was changed in "registerThemeHomepageTour" function since
the homepage tours are supposed to start in edit mode.

task-2375011

closes odoo/odoo#61733

Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>

This prevents some code (in controllers) to retrieve an attachment for a
field that is not stored, as the code only relies on `field.attachment`.
This also makes the field definition more consistent.

closes odoo/odoo#57969

X-original-commit: 13397943d9e953815ae5ce9b01ce812a92903361
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>

When running -i website --test-enable, the test was falsy.
The last page created page was present in matching_page wich one is a criteria
to be excluded from last modified page to avoid duplicate suggested page.

Now we substract correctly them before comparison.

https://github.com/odoo/odoo/blob/saas-13.4/addons/website/controllers/main.py#L243



closes odoo/odoo#57773

X-original-commit: 19319a7f88f474a6410ea1dabc6bcc1ac51e97bb
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>

Now that we will write tour by theme, this part is useless.
We just keep the old steps that will be not covered by future theme tour.

task-2172208

1) Avoid the storage of all country flags as ir_attachment (230+
ir_attachment in a new db) to reduce the filestore of databases.

The country flags are nearly static and not expected to be modified on
Odoo instances.

This change is based on the new "image_url" widget logic (see previous commits).

2) Extend the flag coverage for countries

Add the missing country flags & specify a mapping to provide flags
for overseas administrated countries/territories.

Move it in an external view to be able to place it at a different
location depending on the header template.

Part of https://github.com/odoo/odoo/pull/56427
task-2264627

closes odoo/odoo#56331

Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>

Use case:
When the server is restarted, the python is updated,
but some users may have an ongoing session in a browser tab
This may lead to code being unsynchronized and ultimately to some
odd bugs.

Purpose:
When we are in such a case, that is, the assets were recomputed
after a update of the code and a restart of the server by the request of another user,
notify connected users that assets have changed.
Then propose them to reload the page.

Known caveats:
- This is not a developer's feature.
Since assets computing is ORM cached, they have limited
opportunities to rebuild. Namely, the feature won't trigger
each time the JS has changed, rather, it will
when JS has changed AND the cache has been reset somehow (e.g. when the server is restarted).

- This not a portal/website feature either, but only in backend.
Business clients won't be notified that the JS has changed.

- While requests debug=assets do trigger a recomputing
of the *components* of bundles, they do not save a bundle
This means that the requests that sends the notification
cannot be debug=assets.

Task 2034462

closes odoo/odoo#39875

Signed-off-by: Mathieu Duckerts-Antoine <Polymorphe57@users.noreply.github.com>

That's a not-very-useful subset of OdooTestResult, so:

* make results merge-able (aka add ability to update a result with the
  contents of another)
* remove support for test data files, and transmission of the
  assertion report thing through the data-files loading
* replace "legitimate" uses of assertion report by test result
* have run_unit_tests manipulate and return a result instead of weird
  flags & ternaries

The browser itself would get mostly cleaned up between tours, but the
session object would not get cleaned, and apparently in some cases
that could lead to an incoherent session: a tour would add data to the
session which the next tour (logging in as a different user) would
not (fully) override, leading to a session inconsistency and a Session
Expired exception during the tour.

Fix by not storing the session on the test object, the session is
created during authentication then set on the opener & browser.

closes odoo/odoo#55945

Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>

RATIONALE

Events are sometimes held online, gathering a community. In this merge we
improve Event application to better support full-online events with improved
tracks, wishlists, chat rooms, ...

PURPOSE

Ensure to have a visitor when people registers, in order to enable wishlist
or notifications. Improve visitor model to keep information when people change
device.

SPECIFICATIONS: REGISTRATION FLOW

This commit ensures a visitor is created when a registration is done on an
event. Creation is done only if a visitor does not already exists like all
visitor-based flows.

In case of multiple registrations made by the same visitor, only the first
registration is linked to the created/existing visitor. We take the opportunity
to update the visitor's information based on the registration's infos.

We also add some fields to get all visitors from an event, based on visitor
and registration link. This could be used for example to contact them, like
sending a mailing or push notification to all attendees of an event.

SPECIFICATIONS: VISITOR LOGIN / INFORMATION UPDATE

When a user is linked to a visitor (e.g. when customer logs in) its partner
is propagated to the registration. Using visitor as middle-model it allows
to propagate information through those models, leading to better contact
data notably.

SPECIFICATIONS: VISITOR IMPROVEMENTS + PUSH TOKEN

In this commit we improve visitor behavior. Currently when there are several
visitors that may be linked to the same user, only the last one is kept and
other one are unlinked.

However visitor model holds push tokens, allowing to store approval for push
notifications. Unlinking records is therefore a bad idea as we may loose
information. In order to solve this an intermediate solution is implemented.
A new parent_id field is added on visitors. Instead of unlinking "duplicates"
we link them to the parent and de-activate them. This means more visitors
are present in database, but this is required to keep push tokens.

A better solution would probably be to separate visitor from push tokens
but as this merge targets a stable version it was difficult to do in a clean
way.

LINKS

Community PR #53540
Enterprise PR odoo/enterprise#11384

Task ID-2252655 (Main Online Event task)
Task ID-2283796 (Event B2Basics / Registration Flow
Task ID-2284043 (Visitor-based track wishlist)
Task ID-2283869 (Notify attendees by push)

Co-Authored-By: Aurélien Warnon <awa@odoo.com>
Co-Authored-By: David Beguin <dbe@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>

RATIONALE

Event will soon gain a major update called Event Online, allowing to better
support full-online events. In order to prepare its merge, preparatory merge
are done to lessen the final diff and have a smooth integration in a stable
version (13.3).

PURPOSE

Purpose of this merge is to clean visitor synchronization and tests. It
prepares further improvements to visitor model linked to Event Online.

SPECIFICATIONS

Add anchor methods to somehow merge visitors and update partner linked
to visitors and their sub records.

Main idea would be to be able to

  * avoid unlinking visitors, notably because we have keys linked to them
    allowing push notifications. As a given user may be linked to several
    devices (different keys / different visitors) keeping them in database
    improves push efficiency;
  * allow to link sub-records to a main visitor, like tracked pages history,
    even if multiple visitors are linked to the same identity;

In this stable we cannot remove current unlink of duplicate visitors due
to constraint of partner_id / visitor_id. However those methods allow to
tweak behavior by override. This will be done in future tasks.

LINKS

Task ID 2290016 (improve visitor synchronization and tests)
Prepares Task ID 2252655 (main Online Event task)
Prepares Task ID 2284043 (Visitor-based track wishlist)
PR #54036

X-original-commit: 8a8d2d4412d1b58545ee4f0240cca5114e541b6a
Co-authored-by: Aurélien Warnon <awa@odoo.com>
Co-authored-by: David Beguin <dbe@odoo.com>
Co-authored-by: Thibault Delavallée <tde@odoo.com>

RATIONALE

Event will soon gain a major update called Event Online, allowing to better
support full-online events. In order to prepare its merge, preparatory merge
are done to lessen the final diff and have a smooth integration in a stable
version (13.3).

PURPOSE

Purpose of this merge is to clean visitor synchronization and tests. It
prepares further improvements to visitor model linked to Event Online.

SPECIFICATIONS

Introduce a new configuration parameter in website allowing to set number of
days before de-activating visitors: ``website.visitor.live.days`` . It is
set to 30 days instead of 7 as before.

Purpose of extending delay is to be able to use visitor information a bit
longer in business flows. For example one could contact visitors 2 weeks
after an event to get their feedback. Adding a bit of delay allow to keep
those visitors alive a bit longer by default. Allowing to configure it gives
more flexibility to admins and deployment.

LINKS

Task ID 2290016 (improve visitor synchronization and tests)
Prepares Task ID 2252655 (main Online Event task)
Prepares Task ID 2284043 (Visitor-based track wishlist)
PR #54036

X-original-commit: f83af1d53716499dcad94f363aff609a2f8e55d9
Co-authored-by: Aurélien Warnon <awa@odoo.com>
Co-authored-by: David Beguin <dbe@odoo.com>
Co-authored-by: Thibault Delavallée <tde@odoo.com>

RATIONALE

Event will soon gain a major update called Event Online, allowing to better
support full-online events. In order to prepare its merge, preparatory merge
are done to lessen the final diff and have a smooth integration in a stable
version (13.3).

PURPOSE

Purpose of this merge is to clean visitor synchronization and tests. It
prepares further improvements to visitor model linked to Event Online.

SPECIFICATIONS

Make tests independent from existing database data, notably existing visitors.
Use newly-introduced tools and data. Clean tests and make them easier to
understand, notably connection / disconnection effects. Make more tests about
visitor data: name, partner_id, tracks move from visitor to authenticatedf
visitor, ...

LINKS

Task ID 2290016 (improve visitor synchronization and tests)
Prepares Task ID 2252655 (main Online Event task)
Prepares Task ID 2284043 (Visitor-based track wishlist)
PR #54036

X-original-commit: 015f70dd1ce1394d279f8fbb949948f4845c65fc

RATIONALE

Event will soon gain a major update called Event Online, allowing to better
support full-online events. In order to prepare its merge, preparatory merge
are done to lessen the final diff and have a smooth integration in a stable
version (13.3).

PURPOSE

Purpose of this merge is to clean visitor synchronization and tests. It
prepares further improvements to visitor model linked to Event Online

SPECIFICATIONS

Clean existing visitor tests. Use HttpCaseWithUserDemo and clean bootstrapping
of data.

Introduce a mock for visitor from request allowing to shortcut some visitor /
user synchronization and test directly expected results without too much
boilerplate in tests.

LINKS

Task ID 2290016 (improve visitor synchronization and tests)
Prepares Task ID 2252655 (main Online Event task)
Prepares Task ID 2284043 (Visitor-based track wishlist)
PR #54036

X-original-commit: 4e0d4e7c315b5a9d880754e02966debd6a59c728