Display stat button to groups who have read access to events.

No need to force other workers to reset their cache.

The timezone returned by GeoIP may be unknown by `pytz` due to
incompatibilities between GeoIP and pytz databases (which may be outdated).

In order to avoid the access error when trying to view a partner form
view we should hide the event count stat button for the users who don't have
access to it (must be event_user or event_manager to read this field).

Closes #25225

The controller /event/<model("event.event"):event>/registration/confirm
was broken since the portal user cannot read event.registration objects.

In 9.0 this was not an issue as we browsed and sudoed the
event.registration, but since in 10.0 this line disapeared so did the
sudo which this commit reintroduces.

When saving the media dialog without any selected image, a crash
occurred. Now, it properly closes the dialog.

opw-1858614

This reverts commit c0618d72.

If we applied a link eg. on:

```
<span>hello <b>world</b></span>
```

The system actually gets the "label": hello worldworld because there is
3 nodes:

 text node: hello
 element node: `<b>world</b>`
 text node: world

Also since "hello worldworld" is different than "hello world",
instead of just keeping existing nodes and adding the link, the system
would replace the selected range by:

 `<span><a>hello worldworld</a></span>'

instead of:

 `<span><a>hello </a><b><a>world</a></b></span>`

This commit ignores element nodes when creating a new link, since when
getting the label of the link from the selection, only the text nodes
insides the element nodes have any interest.

There was a second issue because if we had:

```
<i><a href="hello">world</a></i>!
```

and tried to put a link over "world!", the code would decide: "world" is
inside a link so we will just update that link.

Thus we would get:

```
<i><a href="hello">world!</a></i>!
```

instead of:

```
<i><a href="hello">world</a></i><a href="hello">!</a>
```

opw-1848351
closes #25187

Field 'name' (Label) on account_move_line isn't required. When
following the usual flows, it is automatically set by the system.
However, one can manually create move lines without specifying it.

When this occurs, the Sale/Purchase Journal can't be printed
anymore because it causes a crash.

OPW~1857663

Coming from the migration of sale https://github.com/odoo/odoo/commit/f3d715ca94f24f86ce39a4bc6873fe7576ef1860#diff-7ca766af4bd53a0bc808dd3a4ead8317

Closes #14042

This commit closes #24818

Before this rev., if you went to Sales > Sales order, switched to
calendar view, edited the arch such that 'color="state"' is
replaced by 'color="invoice_status"' on the root node, it crashed.

The reason of the crash is that a possible value of the
'invoice_status' selection field is 'to invoice' (it contains a
whitespace), and the JQuery selector didn't wrap the value by
quotes.

OPW~1856305

Closes #19095.

- When receiving a S2S payment feedback from Ogone server, we call the method '_ogone_form_get_tx_from_data' which does a "pre-process" of the data to retrieve the payment.transaction linked to this payment.
  It also checks the hash signature of the data to be sure it comes from Ogone.
  Right after, we call "_ogone_s2s_validate" which make a HTTP call to ogone, to retrieve the data related to the transaction which were already sent by Ogone (maybe to be sure the data comes from Ogone?).

  So instead of calling "_ogone_s2s_validate" we now call "_ogone_s2s_validate_tree" which processes the data from Ogone.
  We are sure they come from Ogone, since they passed the hash signature when calling "_ogone_form_get_tx_from_data".

- Each time we check if a session is valid we create a new cursor.
  This could lead to issues with db_maxconn that limits the number of
connections to the postgresql server.
  In a perfect world, a worker should use a single connection to
postgres to process the request.
  The only known side effect is that the cursor is created earlier in
the execution of the code.

- This commit fixes issues with the longpolling raising
Psycopg2.PoolError exceptions on databases with a lot of clients.

Creation date is a datetime field. However code is giving a date value.
as create date is a magic field with a default value there is actually
no need to override it.

Closes #22447.

[There's a chance mail statistics disappear](https://github.com/odoo/odoo/blob/b3b8a471cc3e02488dcc0da991fd1d828978220d/addons/mass_mailing/models/mass_mailing.py#L519), which is probably not a very good decision, but there it is. Then, `add_click()` produces a 500 error when a user clicks on the mass mailing if the email comes from an old attempt.

Fix is to check the statistic record effectively exists before linking it.

Closes #22447.

Fixed the xpath expression for inserting snippet into Structure tab

Closes #22971

Done at #22971

This commit is related to #24761

Before this commit, display a datetime field with the widget="date" was ignoring
the timezone.

This commit closes #24761

Chatter suggests to include recipients on several objects, notably on
registrations. When a registration is done through a public interface
like website in website_event associated partner is the public user.
In that case proposing to mail the public user does not make sense.
It should propose the real email stored on the registration record.
To fix that we filter the partner if it is linked to the pubic groups.

The fix includes a sudo + context switch in a loop. As this method is
called only on a recordset of one element this has no impact on real use
case. Purpose is to keep the diff minimal.

Closes #23187 .

There was a difference in the tax codes Import Buiten EU (2), some had the tag
'5B Voorbelasting' and other had the tag 'Voorbelasting BTW Bis'.

Link all the codes to '5B Voorbelasting' instead.
This is more consistent with the rest.

Closes #23119

With saas-11.2's 3fbd86bc some trigger towards other fields are improved
but this caused an issue when a inherited field towards a custom
computed field had no depends.

When we created a computed field x_custo on res.partner, we have a
inherited x_custo on res.users automatically created.

Both these fields have a depends computed to `('',)`, this caused an
error for the one on res.partner: but this was ignored with dd048ae7.

Since saas-11.2's 3fbd86bc this also caused an error on the inherited
field but since an inherited field is not "manual" the error was not
ignored. Thus it was not possible to create custom field on a model
inheriting of another model if the fields had no depends.

opw-1854786
closes #25146

Co-authored-by: Raphael Collet <rco@odoo.com>

When updating the qty on a confirmed sale order line,
we want the system to add new procurement qty
for the cancelled procurements. That way you can
leave the cancelled procurements for what they are.

As for consumables stock levels are not that important,
it should be ok to scrap a consumable at all times,
even if the stock becomes negative.

Tests were added to check what happens with a consumable/stockable
product if stays positive/goes negative.

Before this fix, we can create a Bom with both product_id and
product_tmpl_id filled where the product_id is not a variant of the
product_tmpl_id. This is unlogical and will be even trickier when the
user is not able to see the variant field on the BOM.

This fix puts the product_id back to False when the product_tmpl_id
is changed.

It's a backport for https://github.com/odoo/odoo/commit/b795d69ce8aca2e88182c6d6d6b7af54d536f9dd
It also backports this fix https://github.com/odoo/odoo/commit/c49265afa1b0610d52fd356df26491546f1905bf

It also fixes #13578