Currently, when creating a purchase order, if the product has multiple vendor lines (with the vendor selected on the PO), the product description uses information from all the vendor lines; instead of using information from the vendor line that is used for the price.

Steps to reproduce:
-------------------
* Go to the **Purchase** App
* Go to **Products**
* Select any product
* Select the **Purchase** tab
* Add `Vendor Product Name` and `Vendor Product Code` in additional line fields
* Add two vendor lines
  * Line 1:
    `Vendor`: Vendor1 
    `Vendor Product Name`: P1 
    `Vendor Product Code`: A 
    `Price`: 1
  * Line 2:
    `Vendor`: Vendor 1
    `Vendor Product Name`: P1 bis
    `Vendor Product Code`: B
    `Price`: 5
* Select **Orders** > **Request for quotation**
* Create a new quotation
* Select Vendor 1, add the product for which we just added the two vendor lines
> **Observation**: The description of the product shows information from both vendor lines added.

Why the fix:
------------
This behavior was introduced when `name_get` was removed to use `dispay_name` instead.
* https://github.com/odoo/odoo/pull/122085/commits/a8b15c7ab5e2d850d0551a6eb4213bb20a30b210
* https://github.com/odoo/odoo/pull/122085/commits/a8b15c7ab5e2d850d0551a6eb4213bb20a30b210

When adding a product to the purchase order, the onchange on `product_id` is called. The onchange calls the function `_product_id_change`, which itself calls `_get_product_purchase_description`. https://github.com/odoo/odoo/blob/7e9b9494a8d6c4bb8b3800cc0e25fcd3596db75d/addons/purchase/models/purchase.py#L1224 https://github.com/odoo/odoo/blob/7e9b9494a8d6c4bb8b3800cc0e25fcd3596db75d/addons/purchase/models/purchase.py#L1401-L1407

The line `name = product_lang.display_name` calls the function `_compute_display_name`.
* We do have a parnter_id in the context as we have selected a vendor on the purchase order. https://github.com/odoo/odoo/blob/7e9b9494a8d6c4bb8b3800cc0e25fcd3596db75d/addons/product/models/product_product.py#L434
* We don't have a supplierinfo in the context yet but we have multiple supplierinfo with the same partner_id. https://github.com/odoo/odoo/blob/7e9b9494a8d6c4bb8b3800cc0e25fcd3596db75d/addons/product/models/product_product.py#L466-L467 Here we thus have 2 sellers.
* Ultimately, the display name joins the different display names computer for each seller. https://github.com/odoo/odoo/blob/7e9b9494a8d6c4bb8b3800cc0e25fcd3596db75d/addons/product/models/product_product.py#L473-L483

Coming back to the line `self.name = self._get_product_purchase_description(product_lang)`, we now have the name of the purchase order line set as the concatenation of display names from the supplierinfo, i.e `'[A] P1, [B] P1 bis'`.

Once the onchange is called, the function `_compute_price_unit_and_date_planned_and_name` is being called. https://github.com/odoo/odoo/blob/7e9b9494a8d6c4bb8b3800cc0e25fcd3596db75d/addons/purchase/models/purchase.py#L1295-L1302 In the current state, we do not meet the if condition. Indeed, the line has a name (`'[A] P1, [B] P1 bis'`) but it isn't in the default_names (`['[A] P1', '[B] P1 bis']`). It somehow corresponds to a setting where the name of the purchase order line was setup by the user.

With this current fix, the call to `_product_id_change` will set the name of the line with the product information from the company; and not the partner/seller. We also need to add this name to the `default_names` in `_compute_price_unit_and_date_planned_and_name` so that the description gets recomputed with regards to the seller, if any.

I tested the scenario where:
* The second supplierinfo has a smaller unit price when buying 10 products. On the sale order line, when I set the quantity to 20, the unit price is updated as well as the description. The description is updated as `line.name` is indeed in `default_names`.

opw-3802182

Forward-Port-Of: odoo/odoo#158398

How to reproduce:
- Install website_slides with demo data
- Log in from localhost
- Log in from dev.localhost
- Switch to localhost
- (The system property web.base.url is http://dev.localhost:8069 but we are on localhost)
- Go to a course in the back end and click on “Go to website” button

You are redirected to the frontend website home page instead of the course home page.

This fix solves the problem.

Afer correcting this error for the courses (slide.channel), we have found the same problem for:
- event.sponsor
- event.meeting.room
- slide.slide
So we apply the same correction for them.

Technical note: the button "Go to website" uses the open_website_url method of WebsitePublishedMultiMixin that relies on website_url. That method expects a relative URL in the computed field website_url and not an absolute one
(actually, the method already handle adding the website domain, so it expect the relative part). The problem is that the compute method for the field website_url of channel compute an absolute URL. The consequence is that the
user is redirected to the home page instead of the course page (by WebsitePreview, see get path method). In stable, we cannot change easily website_url to make it relative as it is used in other of places (ex.: if we make it relative the share link in the sidebar on the frontend is relative which is not correct and in mail template, the URL might not be correct as the mail system append the default domain for relative URLs). So instead, we override open_website_url to use a relative URL when the website is not defined. If the website is defined on the course, we call the super implementation because a domain change might be required. Note that by doing that, we duplicate the code of _compute_website_url in open_website_url but making the URL relative instead of absolute. So we should clean that in master.

Task-3635856

Forward-Port-Of: odoo/odoo#160114
Forward-Port-Of: odoo/odoo#148103

### Steps to reproduce:

- Activate Subcontracting in the settings.
- Create a storable product
- Create a BOM of type "subcontracting" where the subcontractor is a Portal user (e.g. Joel Willis) for that product.
- Log out and connect as your portal user.
- Go to the website shop and search your product.

### Expected behavior:

The portal user should only be able to see the published products.

### Current behavior:

The portal user sees unpublished products for which he is subcontractor.

### Cause of the issue:

The commit 99b56ec has introduced a subcontracting portal. In order for portal users to be able to interact with product templates, the following rule was added to the "base.group_portal": https://github.com/odoo/odoo/blame/f0a0d596ab716c96de38a5c0f837da2924338d7b/addons/mrp_subcontracting/security/mrp_subcontracting_security.xml#L120-L131 
When you go to the website shop, the records displayed in the shop will be computed here:
https://github.com/odoo/odoo/blob/1c321cd1fe0aabd9cd92c13cd1eae604e5817ae0/addons/website_sale/controllers/main.py#L348 https://github.com/odoo/odoo/blob/f0a0d596ab716c96de38a5c0f837da2924338d7b/addons/website/models/mixins.py#L353-L357 However, during this call, the "ir.rule" added for portal users will be added to the SQL query here:
https://github.com/odoo/odoo/blob/1c321cd1fe0aabd9cd92c13cd1eae604e5817ae0/odoo/models.py#L4682 As such, products (enven if unpublished) for which the portal user is a subcontractor will be fetched and displayed in the shop.

### Fix:

Since the "ir.rule" can not be changed only for flows involving the `website_sale` application, we propose to make a change similar to commit b1f6171 whose purpose is to hide unpublished products for non internal users:
https://github.com/odoo/odoo/blob/1c321cd1fe0aabd9cd92c13cd1eae604e5817ae0/addons/website_sale/models/product_template.py#L105-L108

opw-3768845

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

Forward-Port-Of: odoo/odoo#159420