This update enhances the appearance of PDF Manager actions by removing an unnecessary styling class. Previously, action names had an awkward capitalization style. This change ensures a cleaner and more professional user experience when working with PDF documents within the Enterprise module.

Previously, pdf_manager actions used class "text-uppercase". Action names looked awkward. In this commit, we remove the class and properly display action names.

task-6159317

This update simplifies the process for users to upload multiple documents directly to requests within Odoo. Previously, this was a complex process, and now it's streamlined by introducing a new document type specifically for requests, improving usability and efficiency. This change also addresses an issue with spreadsheet versioning to prevent unnecessary document creation.

Purpose
=======
Allow the users to upload many files on a request.

Simplify the code, and prepare the "multi-requests", by adding a new
document type for the request, instead of relying on complex conditions:

For documents,
`type = binary, attachment_id = False, shortcut_document_id = False`
Or for shortcuts,
`type = binary, shortcut_document_id != False, shortcut_document_id.attachment_id = False`

Task-5417444

This update simplifies alert handling within the IoT payment interfaces (Tyro, Worldline, Six) by standardizing alert messages. Previously, each module had its own alert system; now, a central helper function is used, making the system more consistent and easier to manage. This change improves the overall user experience and maintainability.

Drop the per-module alert wrappers and inline `dialog.add(AlertDialog, ...)` calls in the IoT payment interface and its subclasses, routing them through the base `PaymentInterface` `showAlert(title, message)` helper added in community.

This update introduces a dialog that provides a clear view of the data merging process for duplicate records. Users can now see which fields are contributing to the similarity, how master and source records will be updated, and how related records will be merged, reducing the risk of errors.

[IMP] data_cleaning: add merge details dialog in data_merge.record list view

Before this commit
Users could not easily understand why records were considered
duplicates or what would happen after merging them. Although duplicates
were detected based on similarity rules, there was no easy way to see
which fields contributed to the similarity or what data would be kept
or transferred during the merge.

After this commit
Merge details dialogs are introduced to improve transparency in the
deduplication flow:
- Field Mapping Logic:
 Displays a side-by-side comparison of master and source records for
 fields used in deduplication rules.

- Master-Exclusive Fields:
 Highlights fields whose values are kept exclusively from the master
 record during the merge.

- Master Record Update:
 Provides a preview of how relational fields will be updated during the merge,
 including which records currently linked to the source will be reassigned to
 the master record, and how many related records will be merged into the master.

Impact
Improves user understanding of the deduplication process and enables
users to review similarity criteria and merge results before performing
the merge, reducing the risk of incorrect merges.

Taskid-5952579

This update redesigns the input section on employee payslips to improve usability and aesthetics. The changes include adding specific salary rule categories for Belgian regulations and streamlining the input selection process, resulting in a more user-friendly experience for payroll administrators.

Purpose: Currently the input tab on payslips is very ugly on not user friendly.

Current behavior:
- Show the input section selection if the input usage is employee or payslip
- Always allow edit the input section.
- Add salary rule categories for Belgian salary inputs
- Hide other input list in BE localization if there are no salary adjustments
- removed the last 3 other inputs that are not used

task-id: 6117069

This update adds a simple button to the offer form in Odoo, allowing users to easily regenerate the offer token. This is a security enhancement to protect against compromised email addresses and ensures tokens are always up-to-date. It provides a convenient way to manage offer tokens without needing technical assistance.

Add a button in the cogwheel of the offer form view to regenerate the token in case the email is compromised or the token needs to be updated for any other reason.

Task-5172914

This update links reservation appointments to their corresponding POS orders, streamlining the process for restaurants. It also fixes a previous issue where new partners created through the booking page weren't automatically linked to POS orders. This improves order management and data accuracy.

*: pos_appointment, pos_restaurant_appointment

Link table-reservation appointments to their corresponding POS orders and add a smart button on the POS order form to access the related appointment.

Fix an issue where a partner created via quick create (or not yet loaded in the frontend) from the booking page was not automatically set on the POS order.

Task-5249028

This update enhances the Odoo Report Editor by enabling the insertion of 'bare x2m' data types, which were previously restricted. This change expands the types of data that can be included in reports, providing greater flexibility for report customization. This aligns with prior support for x2m data, as documented in odoo/odoo#231147.

Before this commit, it was not possible to insert bare x2m in the report even though their basic support has been supported for sometime namely with odoo/odoo#231147

After this commit, it is possible to do such a thing

task-6003295

This update removes a confusing distinction between 'Regular' and 'Accrual' holiday allocation types. Now, allocations are automatically categorized based on whether an accrual plan is set up, leading to a simpler and more intuitive user experience. This change improves the overall system clarity and reduces potential errors.

Before:
- Allocations were explicitly divided into Regular and Accrual types through the allocation_type field.
- This separation created an unintuitive UX and added unnecessary complexity to the logic.

After:
- Removed the allocation_type field.
- Simplified the logic so that:
- If an allocation has an accrual plan → it is treated as accrual.
- If no accrual plan is set → it is treated as a regular allocation.
- This improves clarity, simplifies the flow, and makes the behavior more intuitive.

Task-5944548