Before this commit, when the user is in mobile view and go to a task with subtasks and selects a subtask, the form view of that subtask is opened inside a dialog form view instead of opening the record in the main view. Because of that, the chatter for that subtask is not displayed.

This commit opens the form view in the main view instead of opening it inside a form view dialog to be able to display the chatter of the subtask selected.

Steps to reproduce the issue:
----------------------------

1. Install project and go to project app.
2. Create a project A.
3. Add a task inside the project A
4. Add a subtask inside the new task created in step 3
5. Open the form view of the task created in step 3 in mobile
6. Click on the kanban record contained the subtask created in step 4

Expected behavior:
-----------------

The chatter should be displayed in the form view of that subtask to be able to communicate with the customer.

Current behavior:
----------------

Since the form view of the subtask selected is opened inside a form view dialog the chatter for that subtask is not displayed.

task-4278273

Forward-Port-Of: odoo/odoo#220814
Forward-Port-Of: odoo/odoo#200178

**Problem:**
when updating quantity of a product in company A
from a user logged in on company B the svl
are created with wrong values and standard price
is incorrectly updated

**Steps to reproduce:**
- check two companies on the top right of the screen (comp A and comp B)
- create a storable product with a avco category
- make sure that the cost method of the category is avco both when logged in with company A and B
(the cost method is company dependent)
- while logged in with comp A create, confirm, receive and validate a PO for a quantity of 1 and a unit price of 100
- do the same while logged in with comp B but with a unit price of 10
- open the product form (cost should be 100 or 10 depending on the company)
- while logged in on comp B click on the 'on hand' smart button
- update from 1 to 2 the on hand quantity in the WH of comp A
- switch to comp A and come back to prodcut form

**Current behavior:**
the standard price is 55.
additionaly, when opening inventory/reporting/valuation and chossing the product we see that the svl created has a value of 55

**Expected behavior:**
standard price should stay at 100 and the svl
should be created with a value of 100

**Cause of the issue:**
Product_price_udpate_before_done calls get_price_unit to compute the new standard price.
https://github.com/odoo/odoo/blob/750265bac921936a7c29cf73f8f9e926eea4a926/addons/stock_account/models/stock_move.py#L345 Inside get_price_unit, because the move has no unit_price we use self.product_id.standard_price which will take the standard price of comp B
https://github.com/odoo/odoo/blob/750265bac921936a7c29cf73f8f9e926eea4a926/addons/stock_account/models/stock_move.py#L59

opw-4852096

Forward-Port-Of: odoo/odoo#219549
Forward-Port-Of: odoo/odoo#217524

[FIX] html_builder: handle clear button in BuilderDateTimePicker
When the `clear` button was used three consecutive times in the
BuilderDateTimePicker, the input field would remain empty instead of
reverting to its previous value.
This occurred because `useDomState` wasn't being triggered due to no
state change.

Additionally, this fix ensures that the input field now updates
immediately upon using the `clear` button, eliminating the need for
subsequent validation or clicking outside the DateTimePicker.

Steps to reproduce:
- Drop `s_countdown` snippet.
- Open DateTimePicker with the "Due Date" option.
- Click the clear button, then apply.
- Repeat the previous step two more times (for a total of three times).
- The input field remains empty instead of displaying the current date.

-------------------------------------------------------------------------------------------------------

[FIX] html_builder, website: reintroduce null default for options
This commit restores the previous behavior where
`data-customize-website-variable="null"` was used to set a null default
value for website options, ensuring that SCSS correctly applies its own
default styles to elements. This functionality was lost during the
website refactor [1].

Additionally, the `BuilderNumberInput` now defaults to 0, aligning
with the previous default in `UnitUserValueWidget`.

[1]: https://github.com/odoo/odoo/commit/9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/4b596d77d [REL] 18.4.3 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/8e43be7a8 [FIX] header_sizes_ui: preserve row sizes on insert and move ops [Task: 4885579](https://www.odoo.com/odoo/2328/tasks/4885579)
https://github.com/odoo/o-spreadsheet/commit/76a224263 [FIX] evaluation: test array formula invalidation [Task: 4954710](https://www.odoo.com/odoo/2328/tasks/4954710)
https://github.com/odoo/o-spreadsheet/commit/a45061c1d [FIX] auto_complete: remove toggle button for data validation [Task: 4854464](https://www.odoo.com/odoo/2328/tasks/4854464)
https://github.com/odoo/o-spreadsheet/commit/30a11dd57 [FIX] Composer: Remove formatting when pasting external content [Task: 4910559](https://www.odoo.com/odoo/2328/tasks/4910559)
https://github.com/odoo/o-spreadsheet/commit/71ec7d472 [FIX] Formulas: `COLUMN/ROW` spread with range [Task: 4916369](https://www.odoo.com/odoo/2328/tasks/4916369)
https://github.com/odoo/o-spreadsheet/commit/cea21be36 [FIX] spreadsheet_pivot: empty row when number added to char field [Task: 4878778](https://www.odoo.com/odoo/2328/tasks/4878778)

Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya <rmbh@odoo.com>
Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>

**[FIX] website: stop interactions on page edit**
    
    Since [1], interactions are restarted (stopped and started again) when
    the first normalize is triggered in edit. This means that all the
    plugins are started while the interactions are still in their "public"
    state, potentially causing issues down the line.
    By stopping all interactions as soon as the website builder switches to
    edit, we ensure that the DOM is in a valid state for the edition
    plugins.
    
    Note that some edit interactions trigger some plugins shared methods
    (in the website edit service, either through the `shared` object, or
    through the `applyAction` method, whose action itself might then call a
    shared method).
    This is the reason why we do not restart them immediately. They will be
    restarted with the 1st normalize anyways, which happens just after the
    plugins' setup.
    
    [1]: https://github.com/odoo/odoo/commit/9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2

This commit improves the code of the `remove` plugin:

- Rename the `on_remove_handlers` and `after_remove_handlers` resources as `on_will_remove_handlers` and `on_removed_handlers` respectively, to be more consistent.

- Adds a `is_unremovable_selector` resource in order to use it to get the selectors of the elements that are unremovable. It allows to have the resources in the different option plugins, instead of duplicating these selectors in multiple files.

- Merge back the behaviors of `removeElementAndUpdateContainers` and `removeElement` as it was not correct to split them and in order to have only one main `removeElement` function. Its goal was to replace the old `remove_snippet` event, and it was clearly not used everywhere.

- Remove the use of the `remove` plugin where only the JS element `remove` function was needed. We know if a given case needs to activate the parents/siblings and there are other ways to activate them anyway.

- Use the `remove` plugin when this time it was necessary (e.g. when a "Table of Content" is empty).

- Clean the code.

task-4367641

*: website_crm_partner_assign, website_customer, website_membership,
   website_partner

Commit [1] (alongside commits [2] and [3]) introduced a new context key `can_publish_unsudo_main_object` with the goal of properly computing `can_publish` without sudo... but it missed using it properly. The related test was passing... because it was also not properly written.

This commit fixes the issue by using the context key at the proper places. However, this limits the fix to pages and partners at the moment as the bug is not critical in stable versions.

It however fixes a test while run in no-demo (which becomes the norm in later versions). With that in mind, this also changes the view (by *adding* things to be as stable as possible) to go around the use of the context key and make new databases properly compute `can_publish` for all records type. Old databases will keep the old behavior for some models, which leads to displaying the "Publish" button but not be able to use it (access right warning).

[1]: https://github.com/odoo/odoo/commit/d47d824fc484e1592fc4af8d0d378d5a4a579550
[2]: https://github.com/odoo/odoo/commit/1a83b2508b9383e2b7df192f8641751f71f852da
[3]: https://github.com/odoo/odoo/commit/436a167dedb2ed008bcb88e8a4eccafc8d20812c

Related to runbot-161791

Forward-Port-Of: odoo/odoo#220424
Forward-Port-Of: odoo/odoo#219389

**PROBLEM**
Sometimes, the sum of the generated analytic lines for an invoice line doesn't equal the amount on the invoice line. For example, in invoice line with a price of 182.25, with an analytic distribution split into 98% and 2%, the generated analytic lines amount to 182.26 (off by 0.01) because of rounding.

**STEP TO REPRODUCE**
1. install the accounting module and enable the Analytical Accounting option.
2. create an invoice, with a line with a price of 182.25, and a distribution of 98%/2%.
3. confirm the invoice.
4. go to Accounting/Analytics Items and notice the sum of analytical line is 182.26 instead of 182.25.

**CAUSE**
We only apply rounding after having calculated all the analytic line amounts. This mean we will sum the rounding error.
In our example, the computation is like so:
98% of 182.25 = 178.605 rounded to 178.61
2% of 182.25 = 3.645 rounded to 3.65
178.61 + 3.65 = 182.26

**FIX**
We compute the last analytic line for each plan, relatively to the other. `last_line_amount = invoice_price - sum(rounded_other_line_amount)` This ensure that the sum of analytic lines is always equal to the invoice price.

opw-4848784

Forward-Port-Of: odoo/odoo#220614
Forward-Port-Of: odoo/odoo#214736

Currently, an error occurs when a new company is created without selecting a `Fiscal Localization`, and then both companies are selected while creating a new `Analytic Distribution`.

Steps to reproduce:
---
- Install `Accounting` module(without demo)
- Enable `Analytic Accounting`
- Create a New company and switch to it
- Select both companies and Open `Analytic Distribution` and click `New`

Traceback:
---
`TypeError: 'bool' object is not subscriptable`

At [1], we are searching by `account_type`, but if `Fiscal Localization` is not set for the current company, there will be no records in `account.account`. However, due to the multi-company setup, it still return accounts from the first company. In such cases, the `code` field is empty, which causes the `code` to be treated as False.

[1]: https://github.com/odoo/odoo/blob/d155edfd729ab9b53f38939fe24b6d1e7b578083/addons/account/models/account_analytic_distribution_model.py#L55-L58

sentry-6754820454

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

Forward-Port-Of: odoo/odoo#220089

**Current behavior:**
Creating a purchase order in a foreign currency and billing the
product prior to reception will produce 2 issues:
A) The bill line for the product will only make a conversion of
1 single unit of the product with the defined currency exchange
rate, making the amount on the line incorrect when qty > 1

B) When the receipt is finally validated, there will be an
unwanted exchange difference on the journal items generated due
to asymmetrical rounding for the bill AMLs and receipt valuation
AMLs

**Expected behavior:**
Correct bill line currency amounts and symmetric rounding.

**Steps to reproduce:**
1. Set the company currenct to IQD, make a product invoiced on
ordered qty, for sake of example set cost to 500 IQD

2. Create a currency exchange record to USD with a company rate
of `0.00756`

3. Create a PO for 13 of the product created in step 1, with a
discount of 1%

4. Confirm the PO and create the bill -> post it

* Issue A) look at invoice line, see only 1 unit in the
converted currency amount is accounted for by the `balance`

5) Receive the product -> look at the journal items generated
and see that there is a diff of 0.185 IQD

**Cause of the issue:**
A) commit: 90158f6 added a method to try and calculate an AML
balance from its purchase line values, but mistakenly is using
`qty_received` instead of `qty_to_invoice` which explains why
this issue only presents for the bill-before-receipt flow

B) commit: 9f046d5 is using `round=False` context for
`AccountTax.compute_all()` when the expected key is `round_base`

**Fix:**
A) Replace `qty_received or 1` with `qty_to_invoice`
* Also make the test added in 90158f6 more robust

B) Add `round_base=False` alongside the `round` key (not
removing as that existing one could have become expected in this
context)

opw-4689170

Forward-Port-Of: odoo/odoo#220323
Forward-Port-Of: odoo/odoo#205850

<b>Steps to Reproduce:</b>
1. Install Sales and eCommerce modules.
2. Go to Sales → Products, open any product, go to Sales tab, and set a Ribbon.
3. Navigate to Website → Shop, search for the product and open its page.
4. Zoom in or out.

<b>Issue:</b>
- The ribbon on the product image becomes misaligned (shifts away from the image) when zooming in or out 
on the product detail page. This results in a broken visual layout.

<b>Cause:</b>
- A previous change in [PR #175473](https://github.com/odoo/odoo/pull/175473) unintentionally replaced 
the height class (h-100) with width (w-100) on ribbon container, causing layout instability during zoom operations.

<b>Solution:</b>
- Restore the proper layout by reintroducing h-100 to both the ribbon container and inner image div. 
This ensures the ribbon stays correctly positioned relative to the image regardless of zoom level.

<b>opw-4854217</b>

<b>Before FIX :</b>
![image](https://github.com/user-attachments/assets/caace073-9605-4d30-afcc-a470acd54e3c)
<b>After FIX:</b>
![image](https://github.com/user-attachments/assets/9206699b-9c39-4748-8398-d8cf9ae6ab9a)

Forward-Port-Of: odoo/odoo#216545

Problem:
Saving the button snippet after changing its type to a link throws an error because `snippet_key` is `undefined`.

Cause:
The button snippet editor should be disabled if the button is changed to a link. However, `updateOptionsUIVisibility` is only triggered on click events. In this case, the element type changes through the editor itself, not by clicking, so the UI isn't updated accordingly.

Solution:
Trigger a `click` event on the link element programmatically to call `updateOptionsUIVisibility` and hide the button snippet editor when the element is no longer a button.

Steps to reproduce:
- Drop a button snippet
- Click inside the button to edit
- Notice the Button snippet editor appears
- Change the type to "Link" instead of "Primary"
- The Button snippet editor is still visible
- Click the floppy disk icon (save) in the snippet editor -> A traceback occurs

opw-4936796

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

Forward-Port-Of: odoo/odoo#220787
Forward-Port-Of: odoo/odoo#219660

**Steps to reproduce**:
1. Install `helpdesk` only
2. Create a second company and configure a distinct logo for both the default and new companies.
3. Create a Helpdesk ticket under the new company.
4. Use the 'Share Ticket' (gear icon) feature to generate a portal link.
5. Open the link in an incognito window or a different browser (where no user is logged in).
6. Observe the logo shown in the portal navigation bar.

**Observed behavior**:
The portal incorrectly displays the logo and branding of the default/main company, even when the Helpdesk ticket belongs to a different company.

**Issue**:
When no portal user is logged in, the `res_company` used in the portal rendering context defaults to the system’s primary company (`env.company`). The template expects `res_company` to be explicitly set to reflect correct branding. See:
https://github.com/odoo/odoo/blob/880954ebfc1106411b7f7a7d60aee05dfae60893/odoo/addons/base/models/ir_qweb.py#L781

**Solution**:
Explicitly pass `ticket_sudo.company_id` as `res_company` in the portal view context to ensure correct company branding is used.

opw-4855281

Forward-Port-Of: odoo/enterprise#90600

Problem: In a multi-company environment,
users are unable to send templates in non-default
companies despite them creating the template.
A traceback gets thrown because the template
is using the default company on the create user,
instead of the current environment's company.

Purpose: The user should be able to send templates they created in any allowed companies.

Steps to Reproduce on Runbot:
[ADMIN]
1. Install Sign
2. Navigate to Settings > Sign > Enable "Sign Default Terms & Conditions"
3. Create another company and allow Marc Demo access

[Marc Demo]
1. Change to a non-default company
2. Try to send a signature request (e.g. upload pdf to sign > send)
3. Traceback gets thrown

``` 
During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/mylynahy/src/odoo/odoo/fields.py", line 1161, in __get__
    value = env.cache.get(record, self)
  File "/home/mylynahy/src/odoo/odoo/api.py", line 1020, in get
    raise CacheMiss(record, field)
odoo.exceptions.CacheMiss: 'res.company(2,).sign_terms_type'

During handling of the above exception, another exception occurred:
...
odoo.addons.base.models.ir_qweb.QWebException: Error while render the template
AccessError: Due to security restrictions, you are not allowed to access 'Companies' (res.company) records.

Records: BE Company CoA (id=2)
User: Marc Demo (id=6)

This restriction is due to the following rules:
- company rule employee

Note: this might be a multi-company issue.

Contact your administrator to request access if necessary.
Template: sign.sign_template_mail_request
Path: /t/table/tr[5]/t[1]/td/a
Node: <a t-att-href="\'%s/sign/terms\' % record.get_base_url()" class="text-dark"/> 
```


opw-4706828

Forward-Port-Of: odoo/enterprise#85402

Steps to reproduce:
-------------------

- Install 'helpdesk_timesheet' module
- Go to Timesheets and click on `Start` to launch the timer
- Select `VIP Support` as Project
- Create a new ticket

Issue:
------

1. Validation error raised: `At least one analytic account must be set.`
2. When we select a helpdesk project that does not have any ticket linked to it already, the field next to it is set to `Task` (task_id) instead of `Ticket` (helpdesk_ticket_id).

Cause:
------

1. When creating the ticket, we don't provide the default project who got the analytic account linked to it.
2. The field `helpdesk_ticket_id` is hidden because we consider that we the project is not linked to any helpdesk team; this is because we retrieve the projects based on tickets already created only.

Solution:
---------

1. Set the default project in the context when creating the ticket (like for a task).
In the create method, if no team is provided and we have a default project (from `list_value` or the `env.context`), we set the team based on the project if the project is linked to a helpdesk team.
2. Fetch all projects that have `helpdesk_team` field set.

opw-4404097

Forward-Port-Of: odoo/enterprise#91110
Forward-Port-Of: odoo/enterprise#76779

Issue:
The VAT return journal is not created when installing `account_reports` (or `accountant`) after `account`, when the CoA is already created.

Solution:
Create it in the post init hook.

Note that we force the creation of the journal only when `accountant` is installed because it would make noise for invoicing only in most cases. It will still be created automatically when needed.

Also, make the code a little bit more robust:
* instead of mixing "default misc journal" and vat return journal logic, just use one logic
* the function `_get_tax_closing_journal` could return multiple journals but was always used as if it could only contain one
* the function `_get_tax_closing_journal` could not return any journal. Instead, we now create the journal or look for a value on the parent companies if any.
* Manage `show_on_dashboard` in `create` also by using an inverse field. Even if in normal cases the journal will always be created after the company the thus set through `write`, it is not impossible to set it in `create` when creating company branches. Since it is always done when setting the journal on the company, there is no need to set the field in the post-init hook.

Forward-Port-Of: odoo/enterprise#91126

When Debug requests is enable on the whatsapp business account and
user replies with the file, a traceback will appear.

Steps to reproduce the error:
- Install ``whatsapp`` and ``contacts``
- Create a whatsapp business account > Enable Debug requests
- Create a contact > Add a phone number > send whatsapp message with any whatsapp template
- Now reply with the file(ex. pdf or image) in message from the contact's whatsapp.
- Traceback in terminal

Traceback:
``ValueError: A string literal cannot contain NUL (0x00) characters.``

https://github.com/odoo/enterprise/blob/b52a93da7d680b60646cb08a9126cf6c12f5307d/whatsapp/models/whatsapp_account.py#L166
Here, ``message`` contains NUL (0x00) characters because user replies with
the file, value for the ``message`` comes from the below response.

response: https://github.com/odoo/enterprise/blob/b52a93da7d680b60646cb08a9126cf6c12f5307d/whatsapp/tools/whatsapp_api.py#L49-L57

Here, ``res.text`` contains NUL (0x00) characters.
So, it will lead to the above traceback.

sentry-6314521165

Forward-Port-Of: odoo/enterprise#91055
Forward-Port-Of: odoo/enterprise#83274