Steps ----- - Have two companies A and B. - Activate Project Stages, and in the list of stages set the first one of the list as belonging to company A. - Create a project (from 'new' button in list view to be able to set a company at creation) belonging to company B (company B needs to be in the list of selected companies). - Save it: the project's company has changed to company A. Cause ----- If no stage is set on the project at creation, we default to the default stage provided by `_

Steps
-----
- Have two companies A and B.
- Activate Project Stages, and in the list of stages set the first one of the list as belonging to company A.
- Create a project (from 'new' button in list view to be able to set a company at creation) belonging to company B (company B needs to be in the list of selected companies).
- Save it: the project's company has changed to company A.

Cause
-----
If no stage is set on the project at creation, we default to the default stage provided by `_default_stage_id`, which is the first stage in sequence, regardless of its company.
We then change the company of the project to match the stage's company, which overrides the stage set at creation.

Change
-----
If the project has a company set a creation, use the first stage without a company or with the same company as the project.
This is done even if the user doesn't have multiple companies selected, since the `search` on `project.project.stage` can return a stage from another company than the one selected.

opw-4290711

Forward-Port-Of: odoo/odoo#187635

Currently, the extractor looking for terms to translate in spreadsheet files was specifically looking for files ending in "_spreadsheet.json". However, since this version there were new spreadsheets added that ended in "_spreadsheet.osheet.json". The translation extractor couldn't find these and the terms were never extracted, resulting in missing translations. This commit searches for both filename patterns to export the terms. We also make sure that file references are only extracted onc

Currently, the extractor looking for terms to translate in spreadsheet files was specifically looking for files ending in "_spreadsheet.json". However, since this version there were new spreadsheets added that ended in "_spreadsheet.osheet.json". The translation extractor couldn't find these and the terms were never extracted, resulting in missing translations.

This commit searches for both filename patterns to export the terms.

We also make sure that file references are only extracted once per term per file.

Related to https://github.com/odoo/enterprise/pull/75605

Forward-Port-Of: odoo/odoo#191203
Forward-Port-Of: odoo/odoo#190598

**Behaviour before PR:** In website, in some snippets font-size of paragraph like elements is not displayed correctly in toolbar. This issue happens because in `getFontSizeDisplayValue` method if there is no font-size class applied to element then it will set the value of `--font-size-base` css variable which is `16px`. **Behaviour after PR is merged:** Now, `getFontSizeDisplayValue` method will set font-size using `getComputedStyle` if there is no font related class is applied to that

**Behaviour before PR:**

In website, in some snippets font-size of paragraph like elements is not displayed correctly in toolbar. This issue happens because in `getFontSizeDisplayValue` method if there is no font-size class applied to element then it will set the value of `--font-size-base` css variable which is `16px`.

**Behaviour after PR is merged:**

Now, `getFontSizeDisplayValue` method will set font-size using `getComputedStyle` if there is no font related class is applied to that element.

task-4420329




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

Forward-Port-Of: odoo/odoo#191577

* STEP TO REPRODUCE: install event (only CE code), go to Registration Desk then hit button < to go back -> The system warning there are no gantt view * Solution: using existing action `action_event_view` with `clearBreacrumbs` which will help display the menu correctly Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

* STEP TO REPRODUCE: install event (only CE code), go to Registration
Desk then hit button < to go back -> The system warning there are no
gantt view
* Solution: using existing action `action_event_view` with
`clearBreacrumbs` which will help display the menu correctly

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#191295

As we updated the camera interface's logic, we need to add the new library to the IoT Box image. We also removed the python lib patching part, as it was only used by the old camera detection logic. Enterprise PR: [https://github.com/odoo/enterprise/pull/76511](https://github.com/odoo/enterprise/pull/76511) Task: 4432584 Forward-Port-Of: odoo/odoo#192449

As we updated the camera interface's logic, we need to add the new library to the IoT Box image. We also removed the python lib patching part, as it was only used by the old camera detection logic.

Enterprise PR: [https://github.com/odoo/enterprise/pull/76511](https://github.com/odoo/enterprise/pull/76511)
Task: 4432584

Forward-Port-Of: odoo/odoo#192449

Behavior Before the Commit: When generating a new payment link, the system creates a new mandate without explicitly setting the `company_id`. As a result, the default company (`company_id` of the public user, `user_id = 4`) is assigned, which may not match the intended company if the payment is being processed for a company other than the default one. This mismatch between the journal's company and the mandate's `company_id` prevents the payment from being completed. Fix: The `company_id` i

Behavior Before the Commit:
When generating a new payment link, the system creates a new mandate without explicitly setting the `company_id`. As a result, the default company (`company_id` of the public user, `user_id = 4`) is assigned, which may not match the intended company if the payment is being processed for a company other than the default one. This mismatch between the journal's company and the mandate's `company_id` prevents the payment from being completed.

Fix:
The `company_id` is properly set during mandate creation, aligning it with the payment link's associated company and preventing unexpected behavior.

Steps:
1) Configure two companies with accounting setups. 
2) Open the Payment Providers menu.
3) Select SEPA, activate test mode, and ensure it is published. 
4) Duplicate the SEPA payment provider, set the company_id to the second company, activate test mode, and ensure it is published. 
5) Go to any sales order in the first company, generate a payment link, open it, and select SEPA. Enter any fake IBAN — it will process successfully. 
6) Switch to the second company and repeat step 5. You will encounter an error message because the mandate is incorrectly assigned to the first company, preventing payment completion.

Forward-Port-Of: odoo/enterprise#76705

The related community commit fixed the issue where we forgot to extract terms from spreadsheet files ending in "_dashboard.osheet.json" and were file references were added multiple times in the .pot files. This commit re-exports all spreadsheet pot files again using the fixed code. Related to https://github.com/odoo/odoo/pull/190598 Forward-Port-Of: odoo/enterprise#75903 Forward-Port-Of: odoo/enterprise#75605

The related community commit fixed the issue where we forgot to extract terms from spreadsheet files ending in "_dashboard.osheet.json" and were file references were added multiple times in the .pot files.

This commit re-exports all spreadsheet pot files again using the fixed code.

Related to https://github.com/odoo/odoo/pull/190598

Forward-Port-Of: odoo/enterprise#75903
Forward-Port-Of: odoo/enterprise#75605

Following the "nice urls" [task][1] It may happen that the studio's systray item is re-rendered while the actionService is loading a URL with multiple actions In this case, there may be a crash because the SystrayItem would check if the current action (in this case from the virtual controller) is editable. After this commit, there is no crash. part of task-4391729 [1]: https://github.com/odoo/odoo/commit/c63d14a0485a553b74a8457aee158384e9ae6d3f Forward-Port-Of: odoo/enterprise#76

Following the "nice urls" [task][1]
It may happen that the studio's systray item is re-rendered while the actionService is loading
a URL with multiple actions

In this case, there may be a crash because the SystrayItem would check if the current action
(in this case from the virtual controller) is editable.

After this commit, there is no crash.

part of task-4391729

[1]: https://github.com/odoo/odoo/commit/c63d14a0485a553b74a8457aee158384e9ae6d3f

Forward-Port-Of: odoo/enterprise#76694

Since [1], this flow is broken: 1. Install website_helpdesk => You have a "Help" menu with an helpdesk team as url (/helpdesk/customer-care-1) which is created 2. Check: if you publish or unpublish your team, that menu is visible or invisible as a public user. 3. Create a new menu for your website, with that same URL (/helpdesk/customer-care-1) 4. Check: that menu is always invisible as a public user. Even if you remove the first menu. Multiple mistakes were made with [1]: - Th

Since [1], this flow is broken:

1. Install website_helpdesk => You have a "Help" menu with an helpdesk team as url (/helpdesk/customer-care-1) which is created

2. Check: if you publish or unpublish your team, that menu is visible or invisible as a public user.

3. Create a new menu for your website, with that same URL (/helpdesk/customer-care-1)

4. Check: that menu is always invisible as a public user. Even if you remove the first menu.

Multiple mistakes were made with [1]:

- The website menu visibility override code was added twice in two different files.

- The override advertises that this is for "always showing the helpdesk team menus even if they are unpublished" but it is actually meant to be the exact opposite of that.

- The implementation is based on the menu that are linked to the helpdesk teams, not on their URL **.

- The implementation actually bypass the normal visibility computation for all menu URL that start with "/helpdesk", meaning a custom page "/helpdesk-hello" from the user is just broken, so as existing controllers not linked to an helpdesk team (such as /helpdesk/rating).

**: actually this could mean that this feature is just not meant to be given the current state of the codebase: creating a menu with a team URL should just make it so it is forcefully linked to that team or should be prevented if it cannot (?).

[1]: https://github.com/odoo/enterprise/commit/a888fb57ebd2458bc8479e187088cb2e96b811fa

opw-3931376

Forward-Port-Of: odoo/enterprise#76160
Forward-Port-Of: odoo/enterprise#63105

Before this commit, when we did a search in the general ledger for an account code with alpha characters, (ex: `411EDP` in the search bar) the options resulted with `411edp`. It was changed to lowercase. And due to a change in the _name_search of account_account, it now uses like and not anymore ilike. Commit: https://github.com/odoo/odoo/commit/1f589682a9414312b8c15beec5a09e76b16c7c41 The fix is to provide to the options the original search query without lowercase. opw-4388517 Forw

Before this commit, when we did a search in the general ledger for an account code with alpha characters, (ex: `411EDP` in the search bar) the options resulted with `411edp`.

It was changed to lowercase. And due to a change in the _name_search of account_account, it now uses like and not anymore ilike.

Commit: https://github.com/odoo/odoo/commit/1f589682a9414312b8c15beec5a09e76b16c7c41

The fix is to provide to the options the original search query without lowercase.

opw-4388517

Forward-Port-Of: odoo/enterprise#76524

With the changes done to `account.external.tax.mixin` the name of ir.logging is now the module name and not 'Avatax' anymore. So us logs resulted in Avatax US and were not shown by default when opening the window with the window actions. opw-4429151 Forward-Port-Of: odoo/enterprise#76557

With the changes done to `account.external.tax.mixin` the name of ir.logging is now the module name and not 'Avatax' anymore. So us logs resulted in Avatax US and were not shown by default when opening the window with the window actions.

opw-4429151

Forward-Port-Of: odoo/enterprise#76557

### Steps to reproduce: - Install "l10n_cl_edi" - Have a contact of company type with an email and a DTE email - Create a contact of individual type with an email and with the company as parent - In Accounting app create an invoice with the individual as customer - Confirm and open the generated XML - The field CorreoRecep is the individual's email but it should be the DTE of the company ### Cause: The order in the `t-esc` first display the emails before DTE emails. Order of priorit

### Steps to reproduce:
- Install "l10n_cl_edi"
- Have a contact of company type with an email and a DTE email
- Create a contact of individual type with an email and with the company as parent
- In Accounting app create an invoice with the individual as customer
- Confirm and open the generated XML
- The field CorreoRecep is the individual's email but it should be the DTE of the company

### Cause:
The order in the `t-esc` first display the emails before DTE emails.

Order of priority before this commit:
partner email > parent partner email > partner DTE email > parent partner DTE email

### Solution:
Change the order to display the DTE email if possible:

Order of priority after this commit:
partner DTE email > parent partner DTE email > partner email > parent partner email

opw-4288781

Forward-Port-Of: odoo/enterprise#76001
Forward-Port-Of: odoo/enterprise#75917

Camera driver was not working, so we updated the logic to detect camera devices, and improved the one to take pictures. We also caught the opportunity to move IoT Handlers corresponding to `quality` modules to `quality_iot`. Community PR: [https://github.com/odoo/odoo/pull/192449](https://github.com/odoo/odoo/pull/192449) Task: 4432584 Forward-Port-Of: odoo/enterprise#76511

Camera driver was not working, so we updated the logic to detect camera devices, and improved the one to take pictures.
We also caught the opportunity to move IoT Handlers corresponding to `quality` modules to `quality_iot`.

Community PR: [https://github.com/odoo/odoo/pull/192449](https://github.com/odoo/odoo/pull/192449)
Task: 4432584

Forward-Port-Of: odoo/enterprise#76511

Versions: ------------- 16.0 Steps to Reproduce: ---------------------------- 1. Open the Sign app. 2. Switch to the kanban view of sign templates. 3. Upload a document without adding any sign items. 4. Switch to the list view and open the template. 5. In the form view, go to the "Fields" notebook tab. 6. Add 2-3 sign items, then go back to the kanban view. 7. Reopen the template. Issue: --------- An error occurs when trying to sign the template. Cause: ---------- When a

Versions: 
-------------
16.0

Steps to Reproduce:
----------------------------
1. Open the Sign app.
2. Switch to the kanban view of sign templates.
3. Upload a document without adding any sign items.
4. Switch to the list view and open the template.
5. In the form view, go to the "Fields" notebook tab.
6. Add 2-3 sign items, then go back to the kanban view.
7. Reopen the template.

Issue:
---------
An error occurs when trying to sign the template.

Cause:
----------
 When adding sign items in the form view, other required fields are left empty.
These missing values are needed to properly render the items in the PDF iframe.

Solution:
------------
Make the sign items in the "Fields" notebook read-only.

task-4212762

Forward-Port-Of: odoo/enterprise#71017

In project sharing, when the user changes a planned date in task form, a traceback occurs, because the portal user doesn't have the rights on `resource.calendar.attendance`. To solve that, we call the method that get those records with sudo (`_get_tasks_by_resource_calendar_dict`). task-3973305 Forward-Port-Of: odoo/enterprise#72695

In project sharing, when the user changes a planned date in task form, a traceback occurs, because the portal user doesn't have the rights on `resource.calendar.attendance`. To solve that, we call the method that get those records with sudo (`_get_tasks_by_resource_calendar_dict`).

task-3973305

Forward-Port-Of: odoo/enterprise#72695