*: event, website_event, website_hr_recruitment

The functional desire is to be able to access the website app as a basic
internal user and see records views that you can see.
In practice, there are quite a few technical issues preventing that (the
user easily gets hit with "you don't have the rights to access this"
because of internal fields of the main models and screens could maybe be
different or the framework should be a bit more smarter about this.

This commit adds bandaids on the problem to at least allow some access
without warning on some things (by hiding specific fields in the website
views, etc). The main reason for this commit is keeping the no-demo
runbot tests happy (especially in later versions where it became the
standard). In master, this should definitely be reviewed to work more
robustly and more well-thought from a functional point of view.

Some (all?) examples of issues solved: as an internal user without any
access rights (except being an internal user), try to:
- Access the kanban view of events in the website app
- Group the list view of events by "stage" in the website app
- Access the list view or kanban view of jobs in the website app
- Go on an event in the website app, try to access the form view with
  the related top-right button
- Go on a job page in the website app, try to access the form view with
  the related top-right button

Note: the publish button also kinda has the same problem for pages. This
will be fixed in a dedicated PR after this one.

runbot-161791

Forward-Port-Of: odoo/odoo#219356
Forward-Port-Of: odoo/odoo#219128

When dealing with a "return for exchange" case, some SM won't be merged

To reproduce the issue:
1. Confirm a SO with a product
2. Process the delivery
3. Return > Return for exchange
4. Process the receipt
5. Set the SOL qty to 0

Error: a receipt is created. The second delivery should actually be
canceled

This happens because the SM from step 5 is not merged into the SM of
the second delivery. When editing a SOL qty, a procurement is ran
and its values are based on the SOL:
https://github.com/odoo/odoo/blob/66c5d10833af8946ab5d3f887086f9ba08d36ab3/addons/sale_stock/models/sale_order_line.py#L228-L230
https://github.com/odoo/odoo/blob/66c5d10833af8946ab5d3f887086f9ba08d36ab3/addons/sale_stock/models/sale_order_line.py#L378
Where we define a specific `date_deadline`
https://github.com/odoo/odoo/blob/66c5d10833af8946ab5d3f887086f9ba08d36ab3/addons/sale_stock/models/sale_order_line.py#L260

However, when we return for exchange, we also run a procurement, but
its values are defined differently:
https://github.com/odoo/odoo/blob/30e60b55736cfd5f3116ebbc680b49d9113ca419/addons/stock/wizard/stock_picking_return.py#L238
And nothing defines `date_dealine`

Since the values of both SM are not the same, they won't be merged, cf
https://github.com/odoo/odoo/blob/9f8c364f056c8937409f8ed91b8d1fa436c2d7c0/addons/stock/models/stock_move.py#L1119
Hence the creation of the receipt picking

OPW-4688679

Forward-Port-Of: odoo/odoo#218431

**Steps to reproduce:**
- Go to the chatter of any record
- Click on `Send message`
- Click on `Full composer` icon on the bottom right
- Prepare an email with custom subject / body
- Click on `Send Later` and set the scheduled time
- Mail is not sent on scheduled time

**Issue:**
For the timing issue, as the mail is sent by a cron job it obtains a context with `mail_notify_force_send` set to `False` due to the function `_get_eval_context` of `ir.actions.server`.
```
""" Override the method giving the evaluation context but also the
context used in all subsequent calls. Add the mail_notify_force_send
key set to False in the context. This way all notification emails linked
to the currently executed action will be set in the queue instead of
sent directly. This will avoid possible break in transactions. """
```

This context override the `force_send` value used when sending emails notifications. Everything is created properly but the mail is not sent directly and goes to the email queue manager (where it needs to wait until the next execution). This means that the time given previously is not explicitly used to send the mail and the mail is delayed (which doesn't seem to be the expected behavior).
```
if force_send := self.env.context.get('mail_notify_force_send', force_send):
    force_send_limit = int(self.env['ir.config_parameter'].sudo().get_param('mail.mail.force.send.limit', 100))
    force_send = len(emails) < force_send_limit
if force_send and (not self.pool._init or test_mode):
    # unless asked specifically, send emails after the transaction to
    # avoid side effects due to emails being sent while the transaction fails
    if not test_mode and send_after_commit:
        emails.send_after_commit()
    else:
        emails.send()
```

**Fix:**
Overwrite `mail_notify_force_send` value when posting the scheduled message in the cron job.

related: https://github.com/odoo/odoo/commit/df18d5257cef737f3e1d245a8b85769e1fe1a032

opw-4700253

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#211515

**Steps to reproduce:**
- Install `Email Marketing` app
- Setup mail catcher
- Create a first mailing `test_1`
- Insert a dynamic field in the body template to trigger an error (easy way is to setup a dynamic field and then change the `Recipients` type)
- Ensure this mailing has recipients
- Create a second mailing `test_2` with correct template / recipients
- Disable the `Mail Marketing: Process queue` action to prevent automatic processing (optional but could avoid issues)
- For `test_1` and then `test_2`, click on "Send" to trigger the `action_launch()`
- Manually trigger the scheduled action `Mail Marketing: Process queue`
- An error should be raised as expected ('Failed to render QWeb template')
- The mails for `test_2` are properly sent
- However `test_2` remains in `sending` state instead of `done`

**Issue:**
This issue is caused by the transaction rollback when the `test_1` error is raised. When sending the mail, `_action_send_mail` is called with `auto_commit` set to `True` before the mailing state is updated to `done` but after it is set to `sending`.
This means that, when there is an issue later on, the uncommitted changes will be rolled back, which removes the last state modification and the state gets back to `sending` even if the mails were properly sent.
This could lead to unintended behavior such as mailings being retried and resent on next trigger.

**Fix:**
Explicitly called `commit()` after the state update and disabled the `auto_commit` of `_action_send_mail()`.

Could be better to use `post_send_callback` parameter from
`def send(self, auto_commit=False, raise_exception=False, post_send_callback=None):`
but we would need to modify multiple function signatures (which seems bad in stable).

No test was added as the issue require manual committing which is not supported in tests.

opw-4832616

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#214591

### Steps to reproduce:

- Create a storable product tracked by lot
- Create and confirm a receipt for 10 units of that product
- Go to the barcode app and regiter 1 unit
- Exit the picking
- Go back to the picking register the 9 remaining units
- Exit the picking and comeback
#### > The demand of the receipt has been updated from 10 to 19.

### Cause of the issue:

Exiting the picking will launch a call of the `post_barcode_process` in order to keep track of the changes you made without changing the initial demand:
https://github.com/odoo/enterprise/blob/c26c21cec14a234021bb13bbc2684334bc64b70b/stock_barcode/models/stock_move.py#L50-L53 THe first time you enter the picking you have a single move with a quantity of 10. The first time you exit, since you have set a qty_done of 1 (and hence have updated the quantity of the associated move to 1), the `split_uncompleted_moves` will then create a move for a quantity of 9 in order to keep 10 units assigned. The second time you enter the picking both moves are grouped in a single line since the product is tracked by lot, however, when you update the qty_done of that grouped line you will actually only update the quantity of the first move line and its related move. Since the `_truncate_overreserved_moves` was not designed to handle these grouped lines, it does not notice that the combined reservation overcomes the actual demand.

opw-4731803

Forward-Port-Of: odoo/enterprise#89967