Adds an initial Dutch payroll localization with salary rules, payslip inputs, contract settings, company configuration, demo data, and tests. This helps businesses operating in the Netherlands prepare payroll calculations using country-specific parameters for 2025, while also touching shared payslip behavior and Luxembourg declaration logic.

Planning kanban cards now show assigned resources with avatar-style visuals instead of tag labels. This makes roles easier to scan at a glance and preserves helpful color cues for faster identification.

Call the avatar widget on role.resource_ids in kanban view. Get the field color.

related: https://github.com/odoo/odoo/pull/153129
task-3516745

Odoo Studio now lets users choose which field controls whether reference-based Kanban groups are collapsed by default. This gives business teams more flexibility to organize grouped Kanban views in a way that matches their workflow.

Now, if the group_by in the kaban view is a reference, you can specify which variable will define if the group_by is fold by default.

TASK-ID: 3978030

The dropdown used to select related records is now organized more clearly, with guidance and empty-result messages shown first and broader search options placed last. This makes record selection easier to understand and reduces confusing menu states for users.

This commit reworks the many2x dropdown menu. The "start typing" and "no records" menu item are now displayed on top of the menu and the "search more" button is displayed as the last item. The conditions to display some items has changed too. The "start typing" item does not show anymore when record items are displayed and the "no records" item is now always displayed if there are no records. Before the item was displayed if we didn't have the creation permission.

task-4652321

Closed project tasks are now shown as past events in the task calendar, aligning the enterprise calendar behavior with recent community updates. This helps users better understand completed work in context without mistaking it for upcoming activity.

This commit adapts the code according to the changes made in community
to display the closed tasks as past event in the calendar view of tasks.

task-4647219

The Gantt view styling was adjusted so repeated CSS rules are generated only once instead of during every loop. This reduces unnecessary stylesheet output and helps keep the interface code lighter without changing how users interact with Gantt views.

This commit avoids to generate the same CSS rules for each iteration of
the loop instead of setting them once, letting only the rules that
actually depends on the loop to be generated during iteration.

Internal notes in the point of sale preparation display now show colored tags in the product screen and note popup, making them easier for staff to identify quickly. The note handling logic was also cleaned up so future note-related improvements can be maintained more easily.

Before this commit:
------------------------
- Internal notes were not associated with any colors.
- All notes were handled from one place customer_note_button making very messy

After this commit:
-----------------------
- Colors are now displayed for note tags in the product screen and internal notes popup.
- Now OrderlineNoteButton will be treated as a basic component for all notes and rest notes will extend to fulfill the functionalities to make code cleaner and easy to understand.

task-3850741
Related PR: https://github.com/odoo/odoo/pull/183416

On smaller screens in Odoo Studio, the first statusbar button now remains directly visible while additional buttons are grouped into a dropdown. This makes key actions easier to find without overcrowding the interface.

This commit is a follow-up to the one that adapts the statusbar buttons layout on smaller screen to make them more discoverable than moving them all to the CogMenu.

In a nutshell, the first button is displayed like on bigger screens, but the other ones (if any) are folded into a dropdown.

task-4586651

The Knowledge app now uses a more standard way to display font-based icons. This small cleanup improves consistency with common web practices and helps reduce potential display or compatibility issues.

This commit replaces the non-standard HTML tag `<icon>` with the more common `<i>` tag used for font based icons.

Weekly Gantt views can now collapse individual unavailable days, freeing up space for meaningful schedule columns. This makes planning views easier to scan when some days are not usable, especially in dense schedules.

This commit allows to fold single unavailability days when the scale is set to week in order to save space for useful columns since they take a lot of space in this scale.

task-4650363

Field service task menus now show the activity view before the pivot report view. This makes day-to-day task follow-up more immediately accessible while keeping reporting views available.

This commit moves the activity view before pivot view in tasks actions.

task-4647282

Frontdesk users can now access the app from the main menu and quick search after installation. This fixes missing access rights that prevented the app from appearing, restoring normal access for authorized users.

Steps to reproduce:

- install frontdesk
- go on the main menu or try accessing frontdesk through ctrl+k
- admire: no frontdesk to be seen

Fix: explicitate the access rights to the app to make the menus available

runbot build error 160884
task-4657785

Changing the screen orientation for an IoT kiosk no longer sends the request to an invalid address. This ensures kiosk display rotation settings can be updated reliably from the IoT form.

Introduced in commit 27a58bc.

Steps to reproduce:
  1. Configure an IoT box as a kiosk
  2. In the IoT form view, change the Screen Orientation and save your changes.
  3. The request will fail, and if you look in the developer tools you will see the request went to `undefined/hw_proxy...` instead of `<iot_box_ip>/hw_proxy...`.

task-4658229

This change aligns how record creation customizations are written across several Odoo Enterprise apps. It is an internal cleanup that helps automated checks pass consistently and makes future maintenance safer, with no expected day-to-day impact for users.

odoo/odoo#202106

Forward-Port-Of: odoo/enterprise#81772

Forward-Port-Of: odoo/enterprise#81772

In dee57c5a85e26e57159a6eb66de0b2f1f581c64b, which adds prefixes to the states of the model `hr.appraisal`, a search domain on an unrelated model has unfortunately been affected too. This commit fixes the search domain in `_compute_completed_survey_count` which looks at the state of `survey.user_input`, which is not prefixed. Before this commit, the Feedbacks stat button on an appraisal will always show "0 / X", because the filtered state doesn't exist. After this commit, it will show the

In dee57c5a85e26e57159a6eb66de0b2f1f581c64b, which adds prefixes to the states of the model `hr.appraisal`, a search domain on an unrelated model has unfortunately been affected too.

This commit fixes the search domain in `_compute_completed_survey_count` which looks at the state of `survey.user_input`, which is not prefixed.

Before this commit, the Feedbacks stat button on an appraisal will always show "0 / X", because the filtered state doesn't exist. After this commit, it will show the correct number.

Task-id: none

Forward-Port-Of: odoo/enterprise#81712

Create a new module to export payroll data for Prisma. task-3750799 Forward-Port-Of: odoo/enterprise#81500 Forward-Port-Of: odoo/enterprise#72114

Create a new module to export payroll data for Prisma.

task-3750799

Forward-Port-Of: odoo/enterprise#81500
Forward-Port-Of: odoo/enterprise#72114

Steps to reproduce ================== - Install hr_timesheets - Go to Timesheets > All Timesheets - Use the week scale - Scroll to the bottom => Take note of the last record (e.g.: Walter Horton) - Now use a mobile viewport - Make sure the week scale is still applied - Scroll to the bottom => The last record is not the same one as the desktop view Cause of the issue ================== The grid view uses a virtual scroll hook in order to not have to many dom nodes in memory at th

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

- Install hr_timesheets
- Go to Timesheets > All Timesheets
- Use the week scale
- Scroll to the bottom => Take note of the last record (e.g.: Walter Horton)
- Now use a mobile viewport
- Make sure the week scale is still applied
- Scroll to the bottom => The last record is not the same one as the desktop view

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

The grid view uses a virtual scroll hook in order to not have to many dom nodes in memory at the same time. For this to work, we need a consistent row height.

On mobile, when grouping by x amount of fields, they are stacked on top of each other. When grouping by more than 2 fields, there wasn't enough space to display them all.

![image](https://github.com/user-attachments/assets/08f604e3-ae3e-4a73-86d9-41bd4dbfaf9a)

The `grid-template-rows` was set to auto on mobile in order to accomodate that case.

Using auto means we no longer have a consistent row height.

Solution
========

We restore the `gridTemplateRows` and allocate extra space when needed.

![image](https://github.com/user-attachments/assets/5254d7a6-0e32-4321-8e46-abcf0609dcaa)


opw-4208357

Forward-Port-Of: odoo/enterprise#81697
Forward-Port-Of: odoo/enterprise#80476

## Problem When reversing an invoice and making a credit note on a subscription, the email template was still "Invoice: Sending" instead of choosing the credit note template "Credit Note: Sending". The condition on the following code was always True, meaning the super method, that is used to decide which template to take in case of a credit note, was never called. https://github.com/odoo/enterprise/blob/eb1eff85d2119a34997067fedb602e963a5d6f02/sale_subscription/models/account_move_send.py#L9-L1

## Problem
When reversing an invoice and making a credit note on a subscription, the email template was still "Invoice: Sending" instead of choosing the credit note template "Credit Note: Sending". The condition on the following code was always True, meaning the super method, that is used to decide which template to take in case of a credit note, was never called. https://github.com/odoo/enterprise/blob/eb1eff85d2119a34997067fedb602e963a5d6f02/sale_subscription/models/account_move_send.py#L9-L14

## Steps to reproduce
- Take an invoice created through a subscription, reverse it (credit note action)
- Try to send it
- See that the email template is "Invoice: Sending" and not "Credit Note: Sending"

## Fix
A condition was added to differentiate an invoice from a credit note.

opw-4455155

Forward-Port-Of: odoo/enterprise#81143
Forward-Port-Of: odoo/enterprise#79331

Problem: The WhatsApp template's attachment is set on the mail message of the related WhatsApp message. If the user deletes the mail message's attachment, the template's attachment also gets deleted. Solution: Instead of directly linking the template attachment, the attachment will be cloned with the appropriate `res_id` and `res_model` before sending. This ensures that the original template attachment remains intact even if the message attachment is removed. Task-4626855 Forward-Po

Problem:

The WhatsApp template's attachment is set on the mail message of the related WhatsApp message. If the user deletes the mail message's attachment, the template's attachment also gets deleted.

Solution:

Instead of directly linking the template attachment, the attachment will be cloned with the appropriate `res_id` and `res_model` before sending. This ensures that the original template attachment remains intact even if the message attachment is removed.

Task-4626855

Forward-Port-Of: odoo/enterprise#80760

To reproduce the issue: 1. Confirm a SO with partner P 2. Create/Edit an helpdesk team - Returns: True 3. Create a ticket for P 4. Open its form view 5. Click on return Error: a traceback appears "ValueError: Expected singleton: stock. picking()" The return button loads the wizard `stock.return.picking`. In this model, we try to find a related done picking: https://github.com/odoo/enterprise/blob/7215e4abd904ebdff3bd85c2c2f3002b1f5593b1/helpdesk_stock/wizard/stock_picking_retur

To reproduce the issue:
1. Confirm a SO with partner P
2. Create/Edit an helpdesk team
   - Returns: True
3. Create a ticket for P
4. Open its form view
5. Click on return

Error: a traceback appears "ValueError: Expected singleton: stock.
picking()"

The return button loads the wizard `stock.return.picking`. In this
model, we try to find a related done picking:
https://github.com/odoo/enterprise/blob/7215e4abd904ebdff3bd85c2c2f3002b1f5593b1/helpdesk_stock/wizard/stock_picking_return.py#L24-L31
Which, in the above case, does not exist. Later, we call a method on
that picking:
https://github.com/odoo/odoo/blob/8f527e93de2d64111904f1fcc5813e8b8ea0e4ba/addons/stock/wizard/stock_picking_return.py#L100-L104
Where `_can_return` is a `ensure_one` method, hence the error.

The return button is only displayed in some conditions:
https://github.com/odoo/enterprise/blob/3d8bb40fcad00068e12f21b623390c959d3fd19c/helpdesk_stock/views/helpdesk_ticket_views.xml#L35
Here is the problem: `has_partner_picking` can be `True` if we find
some related SOL, which is useless, the only thing that matters are
the related pickings.

OPW-4591280

Forward-Port-Of: odoo/enterprise#81378

In Belgium, certain tax grids (e.g., 81, 82) in the VAT report force negative amounts to 0, as the amounts are carried over to the next period. However, this behavior confuses users, especially VAT experts, as they see 0 instead of the actual negative amount. To improve clarity: - Negative values are now displayed instead of being forced to 0. - The carryover mechanism remains unchanged, and the explanatory infobullet is still displayed. Task-4589150 Forward-Port-Of: odoo/enterprise#797

In Belgium, certain tax grids (e.g., 81, 82) in the VAT report force negative amounts to 0, as the amounts are carried over to the next period. However, this behavior confuses users, especially VAT experts, as they see 0 instead of the actual negative amount.

To improve clarity:
- Negative values are now displayed instead of being forced to 0.
- The carryover mechanism remains unchanged, and the explanatory infobullet is still displayed.

Task-4589150

Forward-Port-Of: odoo/enterprise#79793

The test ensures that pos moves with caba taxes are also included in the tax report and behave the same as non-caba taxes. This was necessary since the closing moves do not create caba entries anymore. (See the community commit) Forward-Port-Of: odoo/enterprise#81747 Forward-Port-Of: odoo/enterprise#81505

The test ensures that pos moves with caba taxes are also included
in the tax report and behave the same as non-caba taxes.
This was necessary since the closing moves do not create caba entries anymore.
(See the community commit)

Forward-Port-Of: odoo/enterprise#81747
Forward-Port-Of: odoo/enterprise#81505

…bling companies Steps to reproduce: 1. Create a company with two branches. 2. Create an asset model in each branch. 3. Go to the main company's chart of accounts. 4. Select the 'Fixed Asset' account and enable 'Automate Asset'. 5. Assign both branches' asset models to 'Asset Model'. 6. Create a vendor bill in one of the branches using the parent company's 'Fixed Asset' account. Observed behavior: - Two assets are created—one for each model assigned to the 'Fixed Asset' account.

…bling companies

Steps to reproduce:
1. Create a company with two branches.
2. Create an asset model in each branch.
3. Go to the main company's chart of accounts.
4. Select the 'Fixed Asset' account and enable 'Automate Asset'.
5. Assign both branches' asset models to 'Asset Model'.
6. Create a vendor bill in one of the branches using the parent company's 'Fixed Asset' account.

Observed behavior:
- Two assets are created—one for each model assigned to the 'Fixed Asset' account.

Expected behavior:
- Only one asset should be created, using the asset model corresponding to the branch.
- Sibling companies should only access their parent's resources (asset models) and not each other's.

This fix ensures that asset models are correctly scoped within their respective branches.

opw-4494439

Forward-Port-Of: odoo/enterprise#81589

Made new pull request as old one https://github.com/odoo/enterprise/pull/79702 was not with correct name. Now Odoo and enterprise pull requests repo has same branch name. Forward-Port-Of: odoo/enterprise#81759 Forward-Port-Of: odoo/enterprise#81335

Made new pull request as old one https://github.com/odoo/enterprise/pull/79702 was not with correct name. Now Odoo and enterprise pull requests repo has same branch name.

Forward-Port-Of: odoo/enterprise#81759
Forward-Port-Of: odoo/enterprise#81335

Issue: Validating deliveries of storable products linked to a subscription will not update the delivered_qty untill the subscription has been invoiced and hence wont allow you to invoice it at all if the invoicing is based on delivered qty. ### Steps to reproduce: - Create a recurring product which inventory is tacked by quantity and which invoicing policy is based on delivered quantity. - Put 10 units in stock. - Create a monthly subscription for 1 unit of that product. - Confirm the s

Issue: Validating deliveries of storable products linked to a subscription will not update the delivered_qty untill the subscription has been invoiced and hence wont allow you to invoice it at all if the invoicing is based on delivered qty.

### Steps to reproduce:

- Create a recurring product which inventory is tacked by quantity and which invoicing policy is based on delivered quantity.
- Put 10 units in stock.
- Create a monthly subscription for 1 unit of that product.
- Confirm the subscription
- Validate the associated delivery
#### > The qty_delivered of the sol is still at 0 and the subscription can't be invoiced.

### Cause of the issue:

Starting from Commit b3ed4416f9b8e37604a9aa38a1f38c3504e22fdf (18.0) we will create the first delivery linked to a subscription rather than waiting for the cron to be triggered. These delivery moves are correctly linked to the related sale order lines of the subscription. However, since future deliveries will also be created and linked to that same sol we need to consider only the outgoing and incoming moves related to the current billing period to determine the qty_delivered. This step is achieved with an override of the `_get_out_going_incoming_moves`: https://github.com/odoo/odoo/blob/a6280b2a5173fad65e62af0ba72cb8721939d709/addons/sale_stock/models/sale_order_line.py#L193-L200 https://github.com/odoo/enterprise/blob/dde492541aa253771f905d0a77650aa35fea0e8c/sale_subscription_stock/models/sale_order_line.py#L27-L34 but this always leads to an empty record set since the order was never invoiced making the`next_invoice_date` and hence the `period_end` coincide with the `start_date` of the order.

opw-4628212

Forward-Port-Of: odoo/enterprise#81749

### Issue: You can not print label for an mo is the qty_producing is at 0. ### Steps to reproduce: - Create a storable product FP tracked by LOT. - Create a bom for that product with 1 operation containing an instruction of type: "print label" - Create and confirm an MO for 10 units and set a lot by hand (but ensure that the qty_producing of the MO is still at 0). - Process the operation in the shopfloor and print label #### > The printed label is empty. ### Cause of the issue:

### Issue:

You can not print label for an mo is the qty_producing is at 0.

### Steps to reproduce:

- Create a storable product FP tracked by LOT.
- Create a bom for that product with 1 operation containing an instruction of type: "print label"
- Create and confirm an MO for 10 units and set a lot by hand (but ensure that the qty_producing of the MO is still at 0).
- Process the operation in the shopfloor and print label
#### > The printed label is empty.

### Cause of the issue:

The qty of label printed depends solely on the qty_producing of the workorder but in case this one is not set we should rather rely on the qty to be produced.
https://github.com/odoo/enterprise/blob/2a91cb194d070879b5e1e5f5fa03178aa2dcc7ec/mrp_workorder/models/quality.py#L344-L351 https://github.com/odoo/enterprise/blob/2a91cb194d070879b5e1e5f5fa03178aa2dcc7ec/mrp_workorder/models/quality.py#L327-L332

opw-4583573

Forward-Port-Of: odoo/enterprise#81478
Forward-Port-Of: odoo/enterprise#80802

### Issue: The current qty forecast of rental orders does not rely on incoming and outgoing quantities that could happen prior to the location period and would hence modify the availability forecast. ### Steps to reproduce: - Create a storable product that can be rented put 100 units in stock. - Create a sale order for 10 units of that product, confirm and confirm the delivery planned for next week. - Create a rental order for 5 units of that product for a period ulterior to the deliv

### Issue:

The current qty forecast of rental orders does not rely on incoming and outgoing quantities that could happen prior to the location period and would hence modify the availability forecast.

### Steps to reproduce:

- Create a storable product that can be rented put 100 units in stock.
- Create a sale order for 10 units of that product, confirm and confirm the delivery planned for next week.
- Create a rental order for 5 units of that product for a period ulterior to the delivery.
- Look at the forecast rentable quantity.
#### > It should be 90 but it is 100.

### Cause of the issue:

The forcasted quantity of a rental order line is based on the `qty_available` of the product:
https://github.com/odoo/enterprise/blob/01b6a70348ffa11a9ead2558571b1ccfa1dd3cbb/sale_stock_renting/models/sale_order_line.py#L115-L129 https://github.com/odoo/odoo/blob/3264e3399918b9627693e78d684ac9ac4ad3bd7d/addons/stock/models/product.py#L31-L43 However, this quantity does not take the incoming and outgoing moves that are planned to happend prior or during the location. In case the renting period starts at an ultarior date than today, it should rather be based on the `virtual_available` quantity of the product:
https://github.com/odoo/odoo/blob/3264e3399918b9627693e78d684ac9ac4ad3bd7d/addons/stock/models/product.py#L44-L55 (note that since we need to take into account each of the incoming and outgoing moves that could happen prior to the location, the `from_date` context key needs to be set to today).

opw-4552760

Forward-Port-Of: odoo/enterprise#81532
Forward-Port-Of: odoo/enterprise#81127

Currently it's not possible for a public user to send themselves a message over whatsapp when the message contains information linked to a record This is because most records do not allow public users from reading them. This bypass is fairly safe as event whatsapp users can only select fields from `_get_whatsapp_safe_fields` which are considered safe to be rendered by SU in the first place. So you cannot simply create any template and render it as a public user. Additional: The phone f

Currently it's not possible for a public user to send themselves a message over whatsapp when the message contains information linked to a record

This is because most records do not allow public users from reading them.

This bypass is fairly safe as event whatsapp users can only select fields from `_get_whatsapp_safe_fields` which are considered safe to be rendered by SU in the first place. So you cannot simply create any template and render it as a public user.

Additional:
The phone formatter should be able to guess the country of a record based on the country of its partner

task-4199766

Forward-Port-Of: odoo/enterprise#81650
Forward-Port-Of: odoo/enterprise#70608

Partial fix of changes applied in: https://github.com/odoo/enterprise/pull/78465 rb-145524 rb-145525 Forward-Port-Of: odoo/enterprise#81753

Partial fix of changes applied in:
https://github.com/odoo/enterprise/pull/78465

rb-145524
rb-145525

Forward-Port-Of: odoo/enterprise#81753

**Problem**: When archiving the only pos config linked to the preparation display, the configuration of the preparation display shows that no pos config is linked to it (it's linked to all pos configs). However, when pos config starts, it doesn't load the preparation display on _load_model as the domain for it is to load when the specific pos config is linked, or no configs are linked. This confuses the clients as the archived pos will not be seen in the preparation display configuration. Ad

**Problem**:
When archiving the only pos config linked to the preparation display, the configuration of the preparation display shows that no pos config is linked to it (it's linked to all pos configs). However, when pos config starts, it doesn't load the preparation display on _load_model as the domain for it is to load when the specific pos config is linked, or no configs are linked. This confuses the clients as the archived pos will not be seen in the preparation display configuration.

Additionally, there is another issue related to live synchronization in version 18.0. When clicking the "Order" button, the request is sent only if the file is linked to a preparation display see here https://github.com/odoo/enterprise/blob/18.0/pos_preparation_display/static/src/override/point_of_sale/pos_store.js#L37.

As a result, if the display is linked to an archived POS config, live synchronization will not function correctly.

- How to reproduce:
    * Assign one pos config to preparation display
    * Archive the assigned config
    * Open another pos config.
    * Kitchen display is not loaded

**Solution**:
Change the domain to include displays with no configs, or with no active config.

opw-4504623

Forward-Port-Of: odoo/enterprise#81722
Forward-Port-Of: odoo/enterprise#80117

Partner autocomplete now uses Dun & Bradstreet for company data instead of Clearbit, improving the reliability of business information suggested in Odoo. Clearbit remains in use only for company logos until the new provider supports them.

We are switching away from Clearbit which is very
unreliable. For that reason we had an autosync
feature which would update IAP's data for a company based on the data provided in Odoo.

Instead, we are now switching to Dun & Bradstreet
which has much more reliable data. Some routes have been changed to target the new API on IAP.

We continue to use Clearbit for the logos which are not provided by DnB (yet).

This is a backport of https://github.com/odoo/odoo/pull/196373 where models, fields, and public methods have been kept to respect the stable policy.

task-4416928

The Zomato and Swiggy point-of-sale integrations now look up tax group names dynamically instead of relying on fixed labels. This helps keep tax calculations accurate when tax labels change, reducing maintenance effort and avoiding future configuration issues.

**=pos_urban_piper_swiggy

Following this commit:
====
- Previously, static values like 'CGST' and 'SGST' were used. However, 'SGST' has been renamed to 'SGST/UTGST'.
- To prevent similar issues in the future, tax group names are now fetched dynamically instead of using hardcoded values.
- This ensures accurate tax computation and better maintainability.

task-4626494

The Project Gantt view now opens correctly even when a user's working schedule is empty. This prevents users from being blocked by an error when viewing project timelines for teams with flexible or missing schedules.

…with empty working schedule

**Issue**
When setting the working schedule to empty, opening the Gantt view is not possible as an error is displayed

Steps to Reproduce:

1. Login as Mitchell Admin
2. Install Employees and Project apps
3. Go to Employees > Contracts
4. Select a contract from Mitchell Admin
5. Empty the Working Schedule Field
6. Set Planning or Attendances as work entries > Save
7. Go to project app
8. Select a project
9. Switch to the Gantt view
10. An error message appears
11. Expected Behavior: Gantt view should be displayed without errors. Actual Behavior: Gantt view is not displayed, and an error message appears.

**Root Cause**

The issue occurs because before processing the work intervals, the system checks for the presence and uniqueness of a calendar. If a user has no assigned schedule, the function attempts to process a None value, which results in an error when calling ensure_one in _attendance_intervals_batch.

**Fix**
To prevent the error, users without a working schedule are skipped when computing valid work intervals. If a user has no assigned schedule, they will not be included in _work_intervals_batch, ensuring the function executes correctly without attempting to process an empty calendar.


opw-4462241

Batch payslip generation no longer fails for employees on fully flexible schedules when their contract has no working schedule. The system now checks each payslip's employee timezone correctly, preventing an error that could block payroll processing.

The bug has been introduced by this commit : https://github.com/odoo/enterprise/commit/4cba2fb58560a95d5ce93eb6e6c1483ef0428ba5

The bug appears when trying to generate batch of payslips with fully flexible working schedules. When the contract linked to the payslip has no working schedule, the check of the timezone is done on the employee linked to the payslip.
The fix only consists on taking the employee of each slip instead of taking the employee on self, which was causing a 'singleton expected' error.

This commit also contains a test for the related fix in the following related PR:

task-4623219

Documents kanban cards once again display tags that have no assigned color, preserving the experience users already expect. The update also includes internal cleanup and test modernization for the Documents area, helping keep future changes safer without changing day-to-day workflows.

Even though it's been commonplace in Odoo for a while,
tags (or more precisely facets) with index-0/False color where still shown
on Documents kanban cards.

This should remain the case functionally as users are not expected to
go and change the color of all their tags, nor can we decide for them
at upgrade (and it'd be too late for many as well).

Task-4645015

Also, cleaning up some test stuff for hoot. See details in individual commits.
Task-3861500

This update fixes internal tests for Project Enterprise scheduling so they no longer incorrectly depend on the timesheet feature being present. It helps keep quality checks stable and reduces the chance of false failures during development or releases.

Same logic as:
https://github.com/odoo/enterprise/pull/79947

rb-145524
rb-145525

Invoice reports now display the authorized signatory image without stretching it to full width. This preserves the signature’s original proportions, making printed or shared invoices look more professional and accurate.

The authorized signatory image is resized and loses it's aspect ratio.

To fix, the w-100 (100% width) class is removed.

OPW-4586108

This fix makes online bank connection records visible when they include accounts for a company the user can access, even if the connection itself belongs to another company. It helps multi-company users find and manage the relevant bank synchronization links without losing access when switching companies.

Description of the issue/feature this PR addresses:

In a multi-company setup, account.online.link records are only visible based on their own company_id. However, these records can have related account_online_account_ids that belong to different companies. As a result, when switching to a different company, users cannot see account.online.link records that have child accounts in that company.

Current behavior before PR:

- account.online.link records are only visible if their company_id matches the user's active company.
- If a link has account_online_account_ids in different companies, users in those companies cannot access the parent account.online.link.

Desired behavior after PR is merged:

- account.online.link visibility is determined by the companies of its related account_online_account_ids.
- If an account.online.link has accounts (account_online_account_ids) linked to a company the user has access to, the record will be visible.



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

This update cleans up how automated tests define views across several Odoo Enterprise apps. It is an internal maintenance change that helps keep test code easier to maintain without changing customer-facing functionality.

## Pull Request HOOT (PRHOOT) 29

This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details.

Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk.

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

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

Also: - Add some missing gettext + proper list formattings - Fix some incorrect English since the modules haven't been translated yet so no translations will be lost. Note that the English of "Allow to export Working Entries to your Social Secretariat" was purposely left bad since it's used in other already translated modules + it's expected that only Belgians will be using the modules and/or the modules will be used only in French/Dutch

Also:

- Add some missing gettext + proper list formattings
- Fix some incorrect English since the modules haven't been translated yet so no translations will be lost. Note that the English of "Allow to export Working Entries to your Social Secretariat" was purposely left bad since it's used in other already translated modules + it's expected that only Belgians will be using the modules and/or the modules will be used only in French/Dutch

Problem: The WhatsApp template's attachment is set on the mail message of the related WhatsApp message. If the user deletes the mail message's attachment, the template's attachment also gets deleted. Solution: Instead of directly linking the template attachment, the attachment will be cloned with the appropriate `res_id` and `res_model` before sending. This ensures that the original template attachment remains intact even if the message attachment is removed. Task-4626855 Forward-Po

Problem:

The WhatsApp template's attachment is set on the mail message of the related WhatsApp message. If the user deletes the mail message's attachment, the template's attachment also gets deleted.

Solution:

Instead of directly linking the template attachment, the attachment will be cloned with the appropriate `res_id` and `res_model` before sending. This ensures that the original template attachment remains intact even if the message attachment is removed.

Task-4626855

Forward-Port-Of: odoo/enterprise#80760