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

Before this commit, when you made a self order at Table, the table selector was trigger and you had to pick one, even if the tableIndicator was there.

In practice, the `selectedTable` in `selfOrder` was removed by the `selectPreset()` function of `EatingLocationPage`

```js
selectPreset(preset) {
	this.selfOrder.currentOrder.setPreset(preset);
	this.selfOrder.currentTable = null;
	this.router.navigate("product_list");
}
```

That was fixed in 18.2 by this commit : https://github.com/odoo/odoo/commit/5e01d444cfd0594dd88a420129375ae1a6fdfc62

The test `self_mobile_auto_table_selection_takeaway_in` as been added.

Steps to reproduce (in runbot 18.1) :
- Go in Point of Sale > Configuration > Settings
- Select the Restaurant
- Set the Self Ordering Method to QR menu + Ordering
- Save
- Get the code using Print QR Codes
- Open the Table: 1 URL in incognito window
- Make sure the Restaurant is Open and the table 1 have no remaining order
- Select Eat In as eating location and make an order
- When you click pay, the table selection displayed

opw-4641352

Forward-Port-Of: odoo/odoo#219907
Forward-Port-Of: odoo/odoo#214300

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/d30327ce0 [REL] 18.3.13 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/270b64f5a [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/65a3252b4 [FIX] evaluation: test array formula invalidation [Task: 4954710](https://www.odoo.com/odoo/2328/tasks/4954710)
https://github.com/odoo/o-spreadsheet/commit/056ce29b9 [FIX] GridComposer: Recompute composer position if we change edited cell [Task: 4879186](https://www.odoo.com/odoo/2328/tasks/4879186)
https://github.com/odoo/o-spreadsheet/commit/994301a64 [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/bcf0f3ebe [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/b9c2fe323 [FIX] Formulas: `COLUMN/ROW` spread with range [Task: 4916369](https://www.odoo.com/odoo/2328/tasks/4916369)
https://github.com/odoo/o-spreadsheet/commit/5626d48fe [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>

**Steps to reproduce:**
1. Install Accounting and l10n_sa_edi
2. Switch to a SA company
3. Go to Accounting > Configuration > Journals > Sales > ZATCA > Re-onboard
4. Create or duplicate a customer invoice > Confirm
5. Click on blue banner "Process Now"
6. Log in as a non-admin user (e.g., Marc Demo) and Switch to a SA company
7. Go to invoice > Open Same invoice > Click to "PRINT"

**Issue:**
- A traceback is raised when trying to access the attachment linked to the ZATCA document.

**Cause:**
- Since commit https://github.com/odoo/odoo/commit/44a4cdb3944a4b722dcfbca5e2947a4372b8501d, access to  EDI document's attachment (`attachment_id`) is restricted to users 
belonging to "Role > Administrator" group (`group_system`).
- This was introduced as part of changes from  Task [#4341594](https://www.odoo.com/odoo/project/49/tasks/4341594)
 As a result, non-admin users (even with accounting rights) are unable to access the attachment causing a traceback.

**Solution:**
- Apply `compute_sudo`to field `l10n_sa_qr_code_str` to bypass the restrictive access rights.
  So even if for any case any other field causes issues in the future, compute_sudo will take care of it

**opw-4923399**

**Description of the issue/feature this PR addresses:**

When inserting a pivot table in a spreadsheet and grouping by an `id` field,
the pivot column or row headers appear blank instead of showing the expected
label. This issue stems from two inconsistencies:

1. The `_sanitizeLabel` logic used to normalize pivot headers did not properly
   handle groupby values for `id` fields that are returned as `[id, label]`
   arrays. It treated them as truthy values but didn't extract the label.

2. The mock `read_group` implementation did not follow backend logic for `id`
   fields. It returned raw integers instead of `[id, display_name]`, breaking
   the label extraction expected by the pivot UI.

**Current behavior before PR:**
- Pivot headers for grouped `id` fields are blank in spreadsheets
- Mock data returns raw IDs, causing the display logic to fail

**Desired behavior after PR is merged:**
- The pivot UI correctly extracts and displays labels for `id` groupings
- The mock `read_group` aligns with backend by returning `[id, label]` for `id`
  fields, matching the behavior of relational fields

Task: 4878685




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

Forward-Port-Of: odoo/odoo#219206

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#220569
Forward-Port-Of: odoo/odoo#200178

**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

<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

**Issue**
Using a Greek letter in the journal's sequence prefix causes a traceback error when confirming an invoice

**Steps to Reproduce**
1. Install the Accounting module
2. Navigate to Accounting > Configuration > Journals
3. Open the Sales journal
4. Under the Advanced Settings tab, set the communication standard to "European"
5. Set the sequence prefix to include Greek letters (e.g., "TΠY")
6. Create and confirm a new invoice
7. Observe the traceback error

**Root Cause**
The prefix is used in calculating the `check_digits` via a base-36 to base-10 conversion. This conversion fails for Greek characters, which are not valid in base-36, leading to an exception

**Fix**
Greek letters in the prefix are transliterated to their Latin equivalents before performing the checksum calculation, ensuring compatibility with the base-36 conversion logic

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

Forward-Port-Of: odoo/odoo#212169

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

Before this PR:
When creating invoices/orders for foreign customers that don't have states defined in their country, both **account.move** and **sale.order** models would incorrectly assign the company's Indian state as the place of supply. This happened because the fallback logic would always use **move.company_id.state_id** without checking if the partner was actually Indian. As a result, foreign customers would be treated as Indian customers in GST calculations, leading to incorrect tax treatment and compliance issues.

After this PR:
Both models now correctly identify foreign customers by checking the partner's country first, before falling back to state-based logic. Foreign customers without states are now properly assigned the foreign state reference (**l10n_in.state_in_oc**) instead of the Indian company's state. This ensures accurate GST treatment where foreign customers are correctly identified as overseas transactions.

Task-4900697

Forward-Port-Of: odoo/odoo#220717
Forward-Port-Of: odoo/odoo#216220

### Description of the issue/feature this PR addresses:

https://github.com/odoo/odoo/commit/ef4c1350df10c186efec79b1414306e325707549 introduced a new exception `ServerActionWithWarningsError`: https://github.com/odoo/odoo/blob/851c46923332aa13c56fbce3a5ed3c5d37a70c92/odoo/addons/base/models/ir_actions.py#L486-L488
This was not registered as an error_dialog. This led to the frontend displaying the entire traceback instead of an error dialog similar to `UserError` when a `ServerActionWithWarningsError` is raised. This commit fixes it by correctly registering the error in `error_dialog` registry category so a more user friendly dialog is displayed with the error contents.

Thanks @brboi for helping with the fix

### Current behavior before PR:

A traceback error is thrown when a `ServerActionWithWarningsError` is raised. Example:
<img width="1896" height="904" alt="image" src="https://github.com/user-attachments/assets/0bfee329-e6c5-4652-a2ac-d41b763e2bdb" />


Video reproducing it: https://drive.google.com/file/d/1C_aE0d_9bP27f388dB1NJLeWHBpsM7AW/view?usp=drive_link (credits: gavb-odoo)

### Desired behavior after PR is merged:

An error dialog similar to UserError which is easier to understand is displayed

<img width="1906" height="799" alt="image" src="https://github.com/user-attachments/assets/d57c5cab-14f2-4f39-9f0c-b8099e8b0089" />


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

opw-4885670

Forward-Port-Of: odoo/odoo#219977

**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

**PROBLEM**
When importing bank statements from the dashboard, it only imports the first batch (by default the first 2000 lines) instead of importing the whole file. This is inconsistent with the behavior of the import done from the reconcilation page. Also, on the import page, the file name is incorrect (it's always `bank_statement_import.csv`)

**STEP TO REPRODUCE**
file to reproduce the issue : [MP 2280260435_movements_-2025-04-01-191536.xlsx](https://github.com/user-attachments/files/20880784/MP.2280260435_movements_-2025-04-01-191536.xlsx)
1. install the accounting module
2. goes on the dashboard, click on the 3-dot button on the kanban for the bank account, and import a file.
3. make sure the file will be imported in multiple batches (reduced the batch size to 200) and click on import.
4. notice how only the first batch was imported.

**CAUSE**
In python,
The `AccountBankStmtImportCSV` class override the execute_import method of the `base_import.import`. In this override, we add a entry in the `messages` list.
 (see `enterprise/account_bank_statement_import_csv/models/account_bank_statement_import_csv.py`)

In JS,
all entry in messages are treated as errors, and the import is interrupted.
 (see `odoo/addons/base_import/static/src/import_model.js`)
https://github.com/odoo/odoo/blob/389b355e7ec761fe8dc2908ac5aec540b0345c48/addons/base_import/static/src/import_model.js#L410-L417

The message entry added in the python was used in the past to automatically open the reconcillation page with the statement lines added. This feature was removed, but not the message.

**FIX**
- Remove the problematic message entry.
- Fix the name of the file in the import action.

opw-4823808

Forward-Port-Of: odoo/enterprise#88343

When a `sign.request` record has `validity` as `False`, attempting to send a reminder via the `_cron_reminder` method leads to a crash.

**Steps to Reproduce:-**
1. Install the `Sign` module.
2. Navigate to the Sign section and click on `Upload PDF & Sign`
3. Upload any PDF document and add your signature, then click `Send`
4. In the new wizard, remove the value for `Valid Until` and enable the `reminder` option. Set the reminder to `every 1 day.`
5. When our scheduled action named `Sign: Send Mail Reminder` executes the following day, it will throw an error.

**Error:-**
`TypeError(''<' not supported between instances of 'bool' and 'datetime.date'') while evaluating 'model._cron_reminder()''`

**Root Cause:-**
The SQL query within the `_cron_reminder()` method retrieves all records where:
- The request is `active` and in the `sent` state.
- Either:
  - `validity < today` or
  - A reminder is due based on `last_reminder + reminder`.

The fetched records are then iterated through at [1].
 [1]
 https://github.com/odoo/enterprise/blob/ac4aeeea98dcf2fc7f06e6a3fabc55e256330e2c/sign/models/sign_request.py#L454

If `validity` is `False`, this comparison raises a `TypeError` because it is invalid to compare a `boolean` with `datetime.date`.

**Solution:-**
- A safety check was added before the comparison between `request.validity` and today's date, ensuring that `request.validity` exists.

Sentry-6727599497

Forward-Port-Of: odoo/enterprise#89646

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#90998
Forward-Port-Of: odoo/enterprise#76779