Purpose:
--------
- It should be easier to visualize maintenance requests than what is possible today. The calendar view is useful but does not provide a comprehensive overview of all equipment or work centers, nor the ability to plan interventions easily.
- It should be much easier to perform maintenance directly from an equipment or work center, instead of creating a maintenance request manually.
- It should also be easy to quickly visualize which equipment is currently undergoing maintenance and update their status once the maintenance is completed.

With this commit:
-----------------
- Makes maintenance planning more easier to manage by adding gantt view by equipment/workcenter.
- Replaced the `Maintenance Calendar` menu with `Planning by Equipment` and `Planning by Workcenter`, providing a more practical way to plan maintenance requests by resources rather than relying on the calendar view.
- Allows creating maintenance requests directly from equipment or work center views, reducing manual effort.
- Prevents scheduling conflicts by showing unavailable workcenter intervals due to workorders or non-working hours.
- Removes the `Request Date` field from maintenance requests as it is redundant with `Scheduled Date`; `Scheduled Date` more accurately reflects the intended start of the maintenance request, whereas `Request Date` only indicates when the request was created.
- The Gantt view defaults to filtering records for the respective workcenter/equipment by `Todo` and `Active`, excluding `Done` and `Archived` maintenance requests, to focus on the remaining active requests.
- It also makes other views (e.g., Kanban, List, Pivot, etc.) of Maintenance Requests available alongside the Gantt view
under `Planning by Equipment` or `Planning by Workcenter`, with the default grouping by equipment or workcenter respectively.
- Improve planning by adding a Plan Popup for unscheduled maintenance requests. It is especially useful when maintenance planners have created requests but are not yet sure when they should be scheduled.
- The Plan Popup applies default `Todo` and `Active` filters to prevent accidental planning of cancelled or already repaired requests.

original-PR by srap: https://github.com/odoo/enterprise/pull/96510
Community PR : https://github.com/odoo/odoo/pull/237165
Upgrade PR: https://github.com/odoo/upgrade/pull/8938

task-4698325

Currently, the `social_push_notifications` module uses Firebase to send push notifications. Over the years, the technology of push notifications has evolved a lot. It is now way more easier to implement push notifications in a web browser without relying on a third service such as Firebase.

This PR introduces a custom implementation for web push notifications used in the `social` and `event` modules. The goals of this change are to: 1) simplify the code base, 2) remove external libraries 3) ensure long term stability 4) improve user privacy and 5) ease debugging.

1. **Simplify the codebase**: The new implementation streamlines the architecture by allowing the server to send push notifications directly to browser-specific delivery servers. As a result, logic related to storing Firebase credentials, interacting with Odoo IAP, and other Firebase-related code is no longer needed and has been removed.
2. **Remove external libraries**: With this implementation, we eliminate the need to install Python libraries like `google_auth` on the Odoo server. This simplifies server setup and reduces the risk of installation or configuration issues.
3. **Ensure long term stability**: Using Firebase ties us to a third-party provider that can change its API, features, pricing, or quotas at any time, with potentially disruptive consequences. With a custom solution, we maintain full control over the codebase and avoid such external risks.
4. **Improve user privacy**: Firebase routes all push notifications through Google's servers, regardless of the user's browser. Our implementation respects user privacy by using the delivery infrastructure native to each browser, avoiding unnecessary exposure to third-party tracking.
5. **Ease debugging**: Debugging is simpler with this implementation, as it removes reliance on a third-party service that previously acted as a black box. Developers can now test push notifications directly from the settings without creating a Firebase account or configuring credentials. Everything works out of the box.

Technical Notes:
---

This PR removes the `use_visitor_timezone` field, which previously allowed notifications to be sent according to each visitor's timezone. The removal is motivated by the following reasons:

1. **Unreliable delivery times**: Delivery could not always be honored due to timezone differences. For example, if the server time is 16:00 and a post is scheduled for 17:00, notifications cannot be delivered on time for visitors in a timezone that is +5 hours ahead. Additionally, the cron job runs only once per hour, which further reduces accuracy when many notifications need to be sent.
2. **No real usage in production**: The option was almost never used in production, indicating limited practical value. Removing it simplifies both the interface and the post configuration logic.
3. **Improved batching for the new notification system**: The new system is designed to send notifications in batches for scalability. Timezone-based delivery made batching difficult and added unnecessary complexity.
4. **Reduce memory usage**: By removing this option, we also reduce memory usage by storing only the last processed push subscription ID, rather than keeping a record of every visitor who has received a notification.

Migration Notes:
---

We still need the IAP codebase with Firebase for the stable versions of Odoo. This codebase can be removed once Odoo 19 is discontinued.

See odoo/odoo#192564

Task-4316624

HR managers need to be notified when payroll-critical employee data is modified by non-officers and must have a clear UI to review and approve these changes before payroll is processed.

This PR introduces the foundations of a payroll review workflow in `hr_payroll`:

### 1. Tracking of payroll-critical fields

* Add `tracking=1` on sensitive fields in `hr.employee` and `hr.version` that should trigger the *to_review* state (e.g. `employee_id`, `contract_id`, `wage`, `schedule_pay`, `resource_calendar_id`, etc.).
* Use `tracking=1` instead of `tracking=True` to:

  * Ensure these changes feed the review workflow.
  * Avoid cluttering the chatter with lower-priority changes.
* The tracking level `< 10` is used by the review system to trigger the *to_review* state.

### 2. Dropdown selection badge widget

* Add a reusable `dropdown_selection_badge` widget to display selection fields as interactive badges in list, kanban, and form views.
* Main features:

  * Configurable colors and icons per selection value.
  * Graceful handling of empty selections with customizable styling.
  * Hover interactions emitting events on the event bus (e.g. to highlight related chatter or show contextual info).
  * Consistent badge styling across all supported view types.

### 3. Review workflow for employee changes

* **Security & access**

  * Restrict modification of payroll-critical fields by non-officers.
  * Automatically set the employee’s state to *to_review* when restricted fields are changed.
  * Ensure proper access rights for payroll officers and managers to review and approve changes.

* **UI & review state management**

  * Integrate the `dropdown_selection_badge` widget in employee list, kanban, and form views.
  * Add a clearly visible review badge and hover states for the review status.
  * Show review warnings in the payroll dashboard to prevent processing unreviewed employees.
  * Update `write()` logic so that:

    * Explicitly setting the state to *to_review* is preserved.
    * The review state is only reset when changes are properly approved, not silently overridden.

* **Payslip validation**

  * Add validation to block payslip processing for employees still requiring review.

This lays the groundwork for a robust payroll review system, ensuring no payslip is processed while employee changes are pending review.

task-5150047

*: pos_enterprise, pos_imin, pos_iot, pos_restaurant

The goal of this commit was to unify the printer logic accross the POS. Before this commit, preparation and receipt was handled differently. Preparation printers were handled in the `pos.printer` model in a dedicated view. 
And receipt printers were handled in the `pos.config` model in the pos.config settings view. Here, printers connected through the iot box and the EPos ones were handled under two different checkbox settings. It was a bit difficult to handle them if a client have a config with preparation printers and receipt printers connected through maneers. 

The goal was also two permit a client to have multiple receipt printers for one POS. Before, only one was permitted. And a printer can also be used by multiple POS config.

After this commit,

- `pos.printer` model is used by every single printer in the POS. The configuration page is located at one place and the pos config setting look a better simple. We can configure one or multiple receipt printers for one pos config in the settings and a default one. The default one is used by default by the POS to print receipt. If the printer isn't accessible (lack of paper, loss of connection,...), a modal appears to offer the client to retry, download, continue (as before this commit) with a last option to choose a fallback printer if one is available in the pos config. 

- two test buttons were created to test a specified printer in the `pos.printer`view and every printer available for a pos config in the `pos.config` settings view (iot and epson ones). On the ticket printed, we can identify easily the printer with its name. 


task : 5266055
community PR : https://github.com/odoo/odoo/pull/236731
upgrade PR : https://github.com/odoo/upgrade/pull/9053