Copy-to-clipboard buttons now use a clipboard icon instead of a clone icon across several Odoo apps. This makes the button purpose clearer for users and improves consistency in the interface.

* = account_reports, appointment, documents, knowledge, spreadsheet_dashboard_edition

Buttons that copy text to the clipboard were previously using the fa-clone icon, which was incorrect. Updated these icons to fa-clipboard.

task-3181092

The Documents app no longer carries outdated skipped mobile tests from the previous testing system. This keeps the test setup cleaner and reduces maintenance work after the move to the newer testing approach.

Since we have migrated all tests from QUnit to Hoot, we remove all the legacy skipped tests from qunit_mobile_suite_tests.

If re-enabled, the document suite tests will have to be converted to Hoot.

task-4028335

This update removes outdated styling rules related to autocomplete dropdowns in the Room module. It helps keep the interface code cleaner and prepares the module for future removal of legacy elements, with no expected functional impact for users.

There are some rules for the ui-autocomplete elements define on some scss files inside the /web/static/src/legacy folder linked to the jQuery-UI autocomplete dropdown.

This commit cleans up these applied rules and remove it if they are not currently needed. We also plan to remove these classes in the future

task-4330695

This update fixes several visual inconsistencies in the Documents app, including button grouping, dropdown borders, modal buttons, loading alignment, and count positioning. Users get a cleaner, more consistent interface with fewer distracting layout issues.

This commit:
1. Removes useless btn-group around "New" button
2. Removes useless borders in the cog dropdown
3. Makes the edit modal buttons more consistent with the rest of the modals
4. Fixes an alignment problem when the loading indicator is displayed
5. Fixes an alignment problem between cog and count

| - | 2 | 3 | 4 | 5 |
|--------|--------|--------|--------|--------|
| before | ![image](https://github.com/odoo/enterprise/assets/8558351/fcd965f4-89c8-4031-a81f-6dcb1fbfb9b6) | ![image](https://github.com/odoo/enterprise/assets/8558351/0dbd0a57-62dc-4171-94af-8db6e8ac88b8) | ![Screenshot 2023-11-07 at 11 37 30](https://github.com/odoo/enterprise/assets/110090660/4c2a450c-313c-4d17-b318-dccca8926e83) | ![Screenshot 2023-11-07 at 11 39 49](https://github.com/odoo/enterprise/assets/110090660/8e0fe921-d75a-484f-bb1b-766090d56d88) |
| after | <img width="227" alt="Screenshot 2024-04-04 at 11 04 49" src="https://github.com/odoo/enterprise/assets/110090660/bc264ad0-28b7-44a4-b4ae-29cf03b3f33a"> | <img width="231" alt="Screenshot 2024-04-04 at 11 03 54" src="https://github.com/odoo/enterprise/assets/110090660/891554fa-7ac8-4f3b-9566-5340e98522ea"> | <img width="196" alt="Screenshot 2024-04-04 at 11 02 57" src="https://github.com/odoo/enterprise/assets/110090660/7479740b-80fd-47af-95e4-8b4fbc8228d9">| <img width="198" alt="Screenshot 2024-04-04 at 11 03 25" src="https://github.com/odoo/enterprise/assets/110090660/32229f8e-16d9-487b-845d-704f7a07e63e">|


task-3580143

This update fixes missing translation markers on user-facing text across several Odoo apps and localizations. It helps ensure labels, messages, and reports can be properly translated for users working in different languages.

Sometimes, developers forget to wrap their strings inside a gettext call. This commit adds those missing calls.

Community: https://github.com/odoo/odoo/pull/177354

This update aligns WhatsApp notification naming between different parts of the system, reducing internal inconsistency. It is a small maintenance change that helps keep the codebase easier to maintain without changing business workflows.

Enterprise counter-part.

https://github.com/odoo/odoo/pull/188878

The delivery IoT package workflow now determines available scales from the specific stock move lines being packed rather than the broader transfer. This keeps the process aligned with recent inventory changes and helps ensure the right scale options appear during packing.

To adjust for the change made in https://github.com/odoo/odoo/pull/171743, available scales in `choose.delivery.package` is now retrieved from the move lines not the picking.

Task-4023634

Child financial reports no longer automatically run setup logic from their parent report, reducing the chance of duplicate or unexpected processing. This makes report behavior more predictable and lowers the risk of errors in localized accounting reports.

Child account reports would execute the _custom_options_initializer method from their root report. It's not intuitive and error prone and can lead to executing _custom_options_initializer multiple times if the child handler inherits it's root handler. Executing root _custom_options_initializer should (only) be done by inheriting the root handler.

Task: 4318404

Since https://github.com/odoo/enterprise/commit/e598fcb48b5e4f0126406a4008f175a88528ba85 the balance sheet report has a custom handler. Make indian balance sheet handler execute super method in it's _custom_options_initializer() do execute parent logic. Forward-Port-Of: odoo/enterprise#74574

Since https://github.com/odoo/enterprise/commit/e598fcb48b5e4f0126406a4008f175a88528ba85 the balance sheet report has a custom handler. Make indian balance sheet handler execute super method in it's _custom_options_initializer() do execute parent logic.

Forward-Port-Of: odoo/enterprise#74574

The query in `_get_invoice_matching_so_candidates` will frequently plan a Seq Scan because of the low selectivity of the conditions. And when it does not, the number of rows returned by the CTE is expected to high. Because of that, filtering the resulting rows by a sequence of `OR` conditions can quickly become slow. In this commit, the `OR` conditions are replaced by `LIKE(ANY(ARRAY[]))` conditions. That way the CTE is only referenced once in the conditions and applying the filter on each ro

The query in `_get_invoice_matching_so_candidates` will frequently plan a Seq Scan because of the low selectivity of the conditions. And when it does not, the number of rows returned by the CTE is expected to high. Because of that, filtering the resulting rows by a sequence of `OR` conditions can quickly become slow.

In this commit, the `OR` conditions are replaced by `LIKE(ANY(ARRAY[]))` conditions. That way the CTE is only referenced once in the conditions and applying the filter on each row is way faster. We also discarded duplicated `text_tokens` to reduce the size of the `ARRAY`.

The reason why using a `LIKE(ANY(ARRAY[]))` is faster is because postgres inlines the CTE in the outer query. This means that it performs a Seq Scan on sale.order and injects the CTE definition of sub.name inside the `WHERE` conditions of the outer query, along with injecting the `WHERE` conditions of the CTE.

So, the regex functions are distributed among the `OR` conditions. I.e. every `OR` condition left operand will contain the regex functions. As those have to be executed for every `OR` condition, this quickly becomes slow.

We can explicitely materialize the CTE to avoid that. This makes postgres evaluate the regex functions only once. But it will still have lots of `OR` conditions to check along with running pattern matching for each one of them.

`LIKE(ANY(ARRAY[]))` avoids this issue. The CTE is still inlined but since we now only have a single condition, the regex functions are only evaluated once and pattern matched once against an array of options. This makes the whole query faster and scale better.

#### speedup

Customer database with 808341 sale.orders. Query timing when increasing the number of text tokens.

| Number of tokens | Before PR | After PR |
|:-------------------:|:----------:|:--------:|
|        2         |     7s    |    1.3s  |
|        5         |     10s   |    1.3s  |
|        10        |     18s   |    1.4s  |
|        20        |     33s   |    1.55s |

opw-4329067
opw-4316765

Forward-Port-Of: odoo/enterprise#74827
Forward-Port-Of: odoo/enterprise#73755

**Specifications:** Users currently land on the 'Company' page by default when there is no context. Instead, users should land on the 'Home' page. **After this PR:** Users will land on the 'Home' page by default. Task-4282430 Forward-Port-Of: odoo/enterprise#72787

**Specifications:**
Users currently land on the 'Company' page by default when there is  no context. Instead, users should land on the 'Home' page.

**After this PR:**
Users will land on the 'Home' page by default.

Task-4282430

Forward-Port-Of: odoo/enterprise#72787

…ing ReferenceNumber to the request opw-4358458 Forward-Port-Of: odoo/enterprise#74751

…ing ReferenceNumber to the request

opw-4358458

Forward-Port-Of: odoo/enterprise#74751

Steps to reproduce ------------------ 1. Change the parent of the "Projects" folder to put it in another folder. 2. Delete that folder. The "Projects" folder will be deleted, despite the constraint preventing it from being deleted. This is because when a relational field is set as `ondelete=cascade`, we don't call the `unlink` on the cascaded records and let the database handle it. Therefore, the constraint is not triggered. With this PR, we check not only the folder being deleted, bu

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

1. Change the parent of the "Projects" folder to put it in another folder.
2. Delete that folder.

The "Projects" folder will be deleted, despite the constraint preventing it from being deleted. This is because when a relational field is set as `ondelete=cascade`, we don't call the `unlink` on the cascaded records and let the database handle it. Therefore, the constraint is not triggered.

With this PR, we check not only the folder being deleted, but also its descendants.

Task-4241631

Forward-Port-Of: odoo/enterprise#74388
Forward-Port-Of: odoo/enterprise#71468

Steps to reproduce ================== - Use a small viewport - Open the Shop Floor - Click on the dropdown toggle next to the search bar => The dropdown goes outside the viewport Cause of the issue ================== In the shopfloor, the search view has a max width of 65%. Solution ======== We can set the max-width of the search bar menu as the minimum between the initial value and 65% opw-4232114 Forward-Port-Of: odoo/enterprise#74801

Steps to reproduce
==================

- Use a small viewport
- Open the Shop Floor
- Click on the dropdown toggle next to the search bar

=> The dropdown goes outside the viewport

Cause of the issue
==================

In the shopfloor, the search view has a max width of 65%.

Solution
========

We can set the max-width of the search bar menu as the minimum between the initial value and 65%

opw-4232114

Forward-Port-Of: odoo/enterprise#74801

Steps to reproduce: ------------------ 1. Create a fresh database of version 17.0 or earlier. 2. Install website_event and website_enterprise modules. 3. Migrate the database to version saas~17.4. 4. Open the website and click on the `Edit` button, Will encounter Traceback Error. Cause: ------ In this [PR](https://github.com/odoo/enterprise/commit/eedf84b093f6c4803f53d7dc0021830c0c7b84cf) there have been changes made using an xpath where the node 'event_upcoming_snippet_hook' is being

Steps to reproduce:
------------------
1. Create a fresh database of version 17.0 or earlier.
2. Install website_event and website_enterprise modules.
3. Migrate the database to version saas~17.4.
4. Open the website and click on the `Edit` button, Will encounter Traceback Error.

Cause:
------
In this [PR](https://github.com/odoo/enterprise/commit/eedf84b093f6c4803f53d7dc0021830c0c7b84cf) there have been changes made using an xpath where the node 'event_upcoming_snippet_hook' is being used. But there exists a view called 'website_event.snippets', where that particular node 'event_upcoming_snippet_hook' is being replaced with some other element/node.
>File(FYR): website_enterprise/views/snippets/snippets.xml

As the view 'website_event.snippets'  has same priority [i.e; 16 default] as the 'website_enterprise.external_snipppets'  view, the 'website_event.snippets' is being executed before than 'website_enterprise. external_snippets' which in result, the node 'event_upcoming_snippet_hook' will get replaced first and will not found for the view 'website_enterprise.external_snippets' when it tries to find that node for making changes and causes the error.

Note: The view 'website_event.snippets' will have smaller id than the view 'website_enterprise.external_snippets' cause it exists before than 'website_enterprise.external_snippets'.

Solution:
---------
Reset the priority of view 'website_enterprise.external_snippets' to 15 so that it will get executed first for finding the node and then gets replaced by the other view 'website_event.snippets'.

Forward-Port-Of: odoo/enterprise#69384

### Steps to reproduce the issue: 1. In a Colombian Company, create an Invoice with a Product with UNSPSC 2. Confirm then Send & Print (check DIAN option in wizard) 3. Access Error: > You are not allowed to access 'Colombian operation modes of DIAN used for different documents' (l10n_co_dian.operation_mode) records. > > This operation is allowed for the following groups: > - Administration/Settings ### Explanation: Access Rights for `l10n_co_dian.operation_mode` are

### Steps to reproduce the issue:

1. In a Colombian Company, create an Invoice with a Product with UNSPSC
2. Confirm then Send & Print (check DIAN option in wizard)
3. Access Error:

>     You are not allowed to access 'Colombian operation modes of DIAN used for different documents' (l10n_co_dian.operation_mode) records.
>
>     This operation is allowed for the following groups:
>     	- Administration/Settings

### Explanation:

Access Rights for `l10n_co_dian.operation_mode` are reserved to `base.group_system`.
During tests, discovered an Access Rights issue with `l10n_co_dian.certificate` as well when trying to "Reload DIAN configuration" of `account.journal`.

### Fix reasoning:

Log note from MASI on the ticket: add Read Access for Invoicing / Billing on `l10n_co_dian.operation_mode`
Since `l10n_co_dian.certificate` should not be openly accessible, we will use sudo to retrieve them while sending the request.
Testing access rights for invoicing, sudo addition and journal flow at the same time.

opw-4242695

Forward-Port-Of: odoo/enterprise#74617
Forward-Port-Of: odoo/enterprise#72623

This error occurs when attempting to ``Print & Send`` an invoice using incorrect credentials for the ``Authorized Certification Provider (PAC)`` or if no credentials are provided and you choose to ``Retry`` after receiving the warning. Steps to reproduce: --- - Install ``l10n_mx_edi`` module - Change the company to ``ESCUELA KEMPER URGATE`` - Invoicing > Customers > Invoices > Select an Invoice - ``Print&Send`` (you will face a warning) > CFDI(Notebook page) > Retry Traceback: ---

This error occurs when attempting to ``Print & Send`` an invoice using incorrect credentials for the ``Authorized Certification Provider (PAC)`` or if no credentials are provided and you choose to ``Retry`` after receiving the warning.

Steps to reproduce:
---
- Install ``l10n_mx_edi`` module
- Change the company to ``ESCUELA KEMPER URGATE``
- Invoicing > Customers > Invoices > Select an Invoice
- ``Print&Send`` (you will face a warning) > CFDI(Notebook page) > Retry

Traceback: 
---
``TypeError: 'int' object is not iterable``

At [1], we are directly passing the ID of self instead of self.

[1]- https://github.com/odoo/enterprise/blob/0f7a4eb991fc59240710c0f8ba78f4da5b889fe6/l10n_mx_edi/models/account_move.py#L1726

sentry-6095574663

Forward-Port-Of: odoo/enterprise#74758

In this PR: - Updated `_cron_send_gstr1_data` to ignore entries with `gstr1_blocking_level` set. - Ensures only unblocked GSTR1 entries are processed by the cron job. Forward-Port-Of: odoo/enterprise#74564

In this PR:
- Updated `_cron_send_gstr1_data` to ignore entries with `gstr1_blocking_level` set.
- Ensures only unblocked GSTR1 entries are processed by the cron job.

Forward-Port-Of: odoo/enterprise#74564

This error occurs when we remove the Start Date while computing a new loan. Steps to reproduce: - Install ``accountant`` module - Create a new loan in ``Loans``(eg: Test) > Click ``Compute`` button - Add any loan amount and remove ``Start Date`` Traceback: ``TypeError: unsupported operand type(s) for +: 'bool' and 'relativedelta'`` [1]- https://github.com/odoo/enterprise/blob/42b7b322d6c720de45661e3370397adaf74fe1f4/account_loans/wizard/account_loan_compute_wizard.py#L79 sentry-6

This error occurs when we remove the Start Date while computing a new loan.

Steps to reproduce:
- Install ``accountant`` module
- Create a new loan in ``Loans``(eg: Test) > Click ``Compute`` button
- Add any loan amount and remove ``Start Date``

Traceback:
``TypeError: unsupported operand type(s) for +: 'bool' and 'relativedelta'``

[1]- https://github.com/odoo/enterprise/blob/42b7b322d6c720de45661e3370397adaf74fe1f4/account_loans/wizard/account_loan_compute_wizard.py#L79

sentry-6093500366

Forward-Port-Of: odoo/enterprise#74686

Currently the view has the default priority and become the main search view for product despite being specific to industry_fsm_sale. It creates issues in inventory at date view where the filters doesn't exist due to this. Forward-Port-Of: odoo/enterprise#74644 Forward-Port-Of: odoo/enterprise#74600

Currently the view has the default priority and become the main search view for product despite being specific to industry_fsm_sale.

It creates issues in inventory at date view where the filters doesn't exist due to this.

Forward-Port-Of: odoo/enterprise#74644
Forward-Port-Of: odoo/enterprise#74600

Fix validation to ensure the CFDI origin field is assigned properly. Prevents cases like `04|`, ensuring the UUID is correctly validated. Before: `{'tipo_relacion': '04', 'cfdi_relationado_list': ['']}` After: `{'tipo_relacion': '04', 'cfdi_relationado_list': []}` Forward-Port-Of: odoo/enterprise#74226

Fix validation to ensure the CFDI origin field is assigned properly. Prevents cases like `04|`, ensuring the UUID is correctly validated.

Before:
`{'tipo_relacion': '04', 'cfdi_relationado_list': ['']}`

After:
`{'tipo_relacion': '04', 'cfdi_relationado_list': []}`

Forward-Port-Of: odoo/enterprise#74226

## Issue: After the changes we have made to sign in 17.0 we stop properly handling the state of the buttons for submit our sign after signing, the problem then is that in Draw mode for example, we are able to submit the sign even before drawing anything, which will allow us to send the document "unsigned", since there will not be any sign. ## Steps to reproduce: 1. Get Sign module. 2. Upload any document to sign. 3. Add sign box and go to sign the document. 4. Now change from Auto to Dr

## Issue: 
After the changes we have made to sign in 17.0 we stop properly handling the state of the buttons for submit our sign after signing, the problem then is that in Draw mode for example, we are able to submit the sign even before drawing anything, which will allow us to send the document "unsigned", since there will not be any sign.

## Steps to reproduce:
1. Get Sign module.
2. Upload any document to sign.
3. Add sign box and go to sign the document.
4. Now change from Auto to Draw.

## Solution: 
We should take into account that it makes sense that everytime we update if our signature is empty, we update the state of the buttons accordingly avoiding this way to be able to sign without an actual sing. The solution address a similar approach at what was already being done with the onChangeName, we move this logic to be handled by a specific function for this buttons 'handleButtonStateChange'.

The fix is part of > [#164410](https://github.com/odoo/odoo/pull/164410)

opw-3874034

Forward-Port-Of: odoo/enterprise#71474
Forward-Port-Of: odoo/enterprise#61981

Branches can access their parent companies' accounts, and generally will just use their parent companies' CoA. Therefore, it makes no sense to create an account `123456 Account Payslip Houserental` in a branch if it already exists in the parent company. Community PR: https://github.com/odoo/odoo/pull/188247 task-none Forward-Port-Of: odoo/enterprise#74604 Forward-Port-Of: odoo/enterprise#74409

Branches can access their parent companies' accounts, and generally will just use their parent companies' CoA. Therefore, it makes no sense to create an account `123456 Account Payslip Houserental` in a branch if it already exists in the parent company.

Community PR: https://github.com/odoo/odoo/pull/188247

task-none

Forward-Port-Of: odoo/enterprise#74604
Forward-Port-Of: odoo/enterprise#74409

Following odoo/enterprise#73372 where we create a new group, so that the admin users don't see all the documents by default, the admin user used in this tour is not able to see anymore the "Folder1" created in the test as it is owned by odooBot with no additional rights. To solve the problem, we set access_internal="edit" on the "Folder1". Task-4361749 Forward-Port-Of: odoo/enterprise#74614

Following odoo/enterprise#73372 where we create a new group, so that the admin users don't see all the documents by default, the admin user used in this tour is not able to see anymore the "Folder1" created in the test as it is owned by odooBot with no additional rights.

To solve the problem, we set access_internal="edit" on the "Folder1".

Task-4361749

Forward-Port-Of: odoo/enterprise#74614

# [FIX] mrp_workorder: always select first option > Depending of the selected work centers in the Shop Floor view, different work center buttons will be visible ("All Mo", "My WO", "Assembly 1", ...) When no work center are selected by default, the first one should be the selected one, but for now, in this case it's always "All MO" who is selected. This commit fixes that, the first button/WC will always the selected one if there is no WC id in the context. # [FIX] mrp_workorder: don't set q

# [FIX] mrp_workorder: always select first option
> Depending of the selected work centers in the Shop Floor view, different work center buttons will be visible ("All Mo", "My WO", "Assembly 1", ...) When no work center are selected by default, the first one should be the selected one, but for now, in this case it's always "All MO" who is selected.
This commit fixes that, the first button/WC will always the selected one if there is no WC id in the context.

# [FIX] mrp_workorder: don't set qty for component added from catalog in the Shop Floor.
> Description
> ===========
> 
> Before this commit, the quantity of a new move raw added through the catalog in Shop Floor was set directly in `_get_new_catalog_line_values`.
With this commit, it is not the case anymore, that way, if we should pick the component (production in 2 steps), the picking will be correctly created (before this fix, the picking was created only after an updated by `_get_new_catalog_line_values`.)
> 
> How to reproduce
> ================
> 
> - In Inventory settings, enable "Multi-Steps Routes";
> - In your warehouse configuration, select the 2 steps options for the manufacture;
> - Create a product with a BoM with at least a component;
> - Create a second product component (but not as a part of the BoM;)
> - Add quantity in stock for both components;
> - Create and confirm a MO for the product with the BoM;
> - Go in the MO's transfer and validate the "Pick Component" picking;
> - Go in Shop Floor, and for this MO, add the second component: click on the gear icon, "Add Component", search your component and click on it.
> 
> If you check your MO in the back end, you'll see no "Pick Component" transfer was created for the added component. That said, if you add more quantity for this component (still through the Shop Floor catalog), you'll see the transfer will be created but 1 qty will be missing.
> 
> Explanation
> ===========
> 
> When in 2 steps manufacture, if a component line is added and the demand is greater than the actual quantity, a Pick Component transfer will be created for this product.
In the catalog, when using it through the Shop Floor, the raw move is
created with an equal quantity and demand, which means no Pick Component
transfer is needed.
That said, when updating an existing raw move through the Shop Floor
catalog, the demand is updated BEFORE the actual quantity, resulting of
the creating/update of the Pick Component transfer.
> 
> To fix this issue, the quantity is not set directly during the move creation but will be updated just after (see related community fix.)

Community PR: odoo/odoo#183532

Forward-Port-Of: odoo/enterprise#71791

**Steps:** - Install the frontdesk module - Open the frontdesk kiosk mode - Change the language from the language selector --- **Description of the issue/feature this PR addresses:** In kiosk mode, changing the language from the selector doesn’t apply the selected language. Instead, the field displays the first language in the list as the default, preventing the correct display of the chosen language. --- **Cause:** The `_get_additional_info` function modifies the language form

**Steps:**
- Install the frontdesk module
- Open the frontdesk kiosk mode
- Change the language from the language selector

---

**Description of the issue/feature this PR addresses:** 
In kiosk mode, changing the language from the selector doesn’t apply the selected language. Instead, the field displays the first language in the list as the default, preventing the correct display of the chosen language.

---

**Cause:**
The `_get_additional_info` function modifies the language format from `_` to `-`, which results in the incorrect language display.

---

**Fix:**
This PR resolves the issue by returning the language directly without calling `py_to_js_locale`, ensuring the correct format and accurate display of the selected language.

task-4223597

Forward-Port-Of: odoo/enterprise#73437

The US payslip PDF needs some changes to make it compliant with the US requirements. Task: 4329656 Forward-Port-Of: odoo/enterprise#74184

The US payslip PDF needs some changes to make it compliant with the US requirements.

Task: 4329656

Forward-Port-Of: odoo/enterprise#74184

The year considered in the holiday attest should be the same as the start of the notice period, not the end which could be in the following year. Task: 4274127 Forward-Port-Of: odoo/enterprise#73133

The year considered in the holiday attest should be the same as the start of the
 notice period, not the end which could be in the following year.

Task: 4274127

Forward-Port-Of: odoo/enterprise#73133

The module description of `account_sepa_direct_debit` in the manifest states that posting an invoice will automatically generate a payment. Actually that feature was dropped in Odoo 13 with commit e3d390c4455c620793c481874b4503fa91bb6125 but the `__manifest__.py` was not updated at that time. This makes the situation uncomfortable where a feature not present in the code is still advertised in the module description. This commit updates the description of the module in the manifest. Forward-P

The module description of `account_sepa_direct_debit` in the manifest states that posting an invoice will automatically generate a payment. Actually that feature was dropped in Odoo 13 with commit e3d390c4455c620793c481874b4503fa91bb6125 but the `__manifest__.py` was not updated at that time. This makes the situation uncomfortable where a feature not present in the code is still advertised in the module description.

This commit updates the description of the module in the manifest.

Forward-Port-Of: odoo/enterprise#74532
Forward-Port-Of: odoo/enterprise#73380

## [IMP] hr_payroll_expense: Add Error when no expense rule is found This commit improves "expenses to be reimbursed in a payslip "config Before this commit: There was no way for a user to know if a payslip set to be reimbursed in a payslip would never be due to a bad configuration. After this commit: The user now gets an error when choosing to reimburse an expense through a payslip, asking to first setup a proper rule. task-id: 4273421 ## [IMP] hr_payroll_expense: Add a test

## [IMP] hr_payroll_expense: Add Error when no expense rule is found
This commit improves "expenses to be reimbursed in a payslip "config

Before this commit:
There was no way for a user to know if a payslip set to be reimbursed
in a payslip would never be due to a bad configuration.

After this commit:
The user now gets an error when choosing to reimburse an expense
through a payslip, asking to first setup a proper rule.

task-id: 4273421


## [IMP] hr_payroll_expense: Add a test ensuring no sheet if no rule
In https://github.com/odoo/enterprise/commit/6e4a94f530643a9ad7b461d49e149a339bc6a341, the issue of expense sheets being linked to payslips
whose structure missed an expense ruled was resolved,
but no test was added.

This adds a test covering this case, to make sure it never happens again

Forward-Port-Of: odoo/enterprise#74505
Forward-Port-Of: odoo/enterprise#72912

Bug === The many2one to the partner of the share panel can be really slow, because it will count all partner of the database. We don't need that count, setting the value to 1 will never call `search_count`. Task-4364119 Forward-Port-Of: odoo/enterprise#74681

Bug
===
The many2one to the partner of the share panel can be really slow, because it will count all partner of the database. We don't need that count, setting the value to 1 will never call `search_count`.

Task-4364119

Forward-Port-Of: odoo/enterprise#74681

Some strings weren't translatable/were missing from the pot files to be translated. Since these strings weren't translatable (i.e. no lost work), they have been updated to be more grammatically correct + understandable where useful. opw-4321317 Forward-Port-Of: odoo/enterprise#74418 Forward-Port-Of: odoo/enterprise#73854

Some strings weren't translatable/were missing from the pot files to be translated. Since these strings weren't translatable (i.e. no lost work), they have been updated to be more grammatically correct + understandable where useful.

opw-4321317

Forward-Port-Of: odoo/enterprise#74418
Forward-Port-Of: odoo/enterprise#73854

The links created with the many2OneGridRow widget won't work correctly. This commit, will change the link to the new format. This commit is a followup of https://github.com/odoo/odoo/commit/98f748603ed7677265280d33b0b4750010f71fe0 Forward-Port-Of: odoo/enterprise#74543 Forward-Port-Of: odoo/enterprise#74461

The links created with the many2OneGridRow widget won't work correctly.

This commit, will change the link to the new format.

This commit is a followup of https://github.com/odoo/odoo/commit/98f748603ed7677265280d33b0b4750010f71fe0

Forward-Port-Of: odoo/enterprise#74543
Forward-Port-Of: odoo/enterprise#74461

The civil status field in the swizz localization has terms that are not exported to be translated. Also, There was a typo in one of the terms. This commit fixes the typo and exports the terms to be translated later on. Opw-4292046 Opw-4278798 Community: https://github.com/odoo/odoo/pull/186473 Forward-Port-Of: odoo/enterprise#74627 Forward-Port-Of: odoo/enterprise#73406

The civil status field in the swizz localization has terms that are not exported to be translated. Also, There was a typo in one of the terms. This commit fixes the typo and exports the terms to be translated later on.

Opw-4292046
Opw-4278798

Community: https://github.com/odoo/odoo/pull/186473

Forward-Port-Of: odoo/enterprise#74627
Forward-Port-Of: odoo/enterprise#73406