Purpose
=======

The goal is to make timesheet entry as quick and effortless as possible for consultants.
Easier time logging means fewer forgotten entries, better visibility on activities, and ultimately
a higher billable rate for the department.

This PR is the first step in a series of features aiming to address this.
It adds a new "Timesheets Assistant" feature, tracking the activity of users on their computer,
and suggesting timesheet entries based on this data.

Implementation
==============

ActivityWatch
-------------

Most of this new feature requires installing the tool [ActivityWatch](https://activitywatch.net/).

This tool collects data through *watchers*, which are units tasked with one type of tracking.
By default, there is one watcher tracking the name of the active window, and one tracking whether
or not the user is actively using the computer.
There are also additional watchers that can be installed by the user, the most important being
a browser extension to get extra information about which websites were visited.
This is used, among other things, to detect which activities were done in Odoo.

Watchers send their data to a local server, which is then queried by the JavaScript code in Odoo.
It is important to stress that this data only stays on the **client-side** and is never sent to
the server, until the user decides to use it to create timesheets.

Processing the Data
-------------------

First of all, we start by retrieving the calendar events and planning shifts we can find for the
current user, if the right modules are installed. We then add the data collected by ActivityWatch.

We have two ways of processing that data:

- **Odoo Activities**: With the browser watcher enabled, we track whenever the user is working on
a record that we could connect to a task or a project. We then consider that subsequent activities
were connected to that project, until another project/task detection.
- **Matching Rules**: This allows filtering activities based on a regex that is run on a concatenation
of the name and URL (if present), and matching  them to a label that will show up in the suggestions
of the timesheets assistant. The labels can contain placeholders that will be replaced with elements
captured by the regex. Rules can also optionally be bound to a project or task, in which case
they will count as a project/task change for subsequent activities.

The precedence order for the data is as follows:

1. Calendar Events
2. Planning Shifts
3. Matching Rules, in order of ascending sequence
4. Odoo Activities

In case of overlapping events from different sources, the one with lower precedence will be ignored
for the duration of the overlap.

Suggestions
-----------

This results in aggregates of durations, with a label, and optionally a project or task.
In the assistant interface, they are displayed in a list that can be (or not) grouped by the matched
projects and tasks. The user can then choose one or more activities to convert to a timesheet,
or dismiss the suggestions. Suggestions hidden this way will not show up again.

Existing timesheets for the current employee are also shown on the right side of the assistant UI.
They can be edited or deleted from there.

When the user created a timesheet from activities, we track which project and task they match it to.
This data is used to automatically match activities to projects and tasks based on the user's habits.

---

Task-5167914

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

Steps to reproduce:
- Enable Rental pickings
- Create a rental for a product, for 4 quantity
- Process the delivery
- Open the barcode app and open the reception
- Scan the product once and validate

Issue:
The receipt is validated without issues nor warning, despite being incomplete.

This is due to a bad mix of two changes:
- #60801, which always sets the rental receipt as return of the delivery
- #48788, which removes the backorder check for returns in barcode

For regular returns made in barcode, it makes sense to avoid the backorder check, as from here we're processing a full picking return and we'd have the confirmation pop every time.

However, things are different for rental receipts, as despite them being set as returns of the delivery, they're proper receipts that need to handle the partial receipt.

To avoid the issue, rather than removing the backorder check whenever there's a return linked to the picking, now also checks that there isn't a rental order linked to the picking.

opw-5265874

Forward-Port-Of: odoo/enterprise#101387

Version:
- saas-18.4

Steps to reproduce:
- Install website_sale_subscription
- Create a subscription product without a plan
- Open product on eCommerce

Issue:
- When viewing a subscription product without a subscription plan in the eCommerce shop, the system incorrectly shows the warning "This subscription is not compatible with the one already in your cart. Please order them separately or empty your cart."
- This happens even if the cart is completely empty.
- The method _is_add_to_cart_possible doesn’t find any valid combination to add to the cart, and because the product is marked as recurring, it always triggers the wrong message.

Solution:
- Add a condition to check if current product have any  recurring price set if not then it will show the correct warning that 'This product has no valid combination.'

Impact:
- Users see clear and correct warnings on products without a subscription plan.

task-5255749

Forward-Port-Of: odoo/enterprise#102251
Forward-Port-Of: odoo/enterprise#100929

Purpose: In the Guatemalan localization, when an electronic invoice is created, the email template to the customer already contains the PDF version of the DTE. However, the XML file, generated and sent to the SAT through Infile, is not attached to that email. Even though the SAT and Infile deliver the XML to the customer, it is more convenient and transparent if Odoo includes it directly in the outgoing invoice template email, so the customer receives both files in one place.

Before this commit:-
- Only PDF version is attached by default in customer email for e-invoices.
- Name of edi document is prefixed with `Demo` if company is in demo environment (check parent company's environment in case of child company) (e.g. DEMO_certificate_INV_2025_00001.xml) and prefixed with `SAT` if company is in testing or production environment(e.g. SAT_certificate_INV_2025_00001.xml).

After this commit:-
- XML version is also attached by default along with PDF in customer email for e-invoices.
- Name of edi document is always prefixed with `SAT`.

task-5224521

Forward-Port-Of: odoo/enterprise#102322
Forward-Port-Of: odoo/enterprise#98978

Steps to reproduce:
-------------------------
1. Install Salary Configurator module.
2. Create a new user and assign Officer rights in Employees and Recruitment.
3. Login with that user.
4. Create a new application and move it to 'Contract proposal' stage.
5. Click on the 'Generate Offer' button.

Observation:
-------------------------
An Access Error occurs, denying Read access to the `final_yearly_costs` field.

Issue:
-------------------------
In earlier versions, users had an additional access right that allowed them to access contract fields. After the HR modules were refactored, only HR Administrators and Payroll Users retained access to those fields. As a result users with only Officer rights in HR encountered an access error when generating an offer.

Solution:
-------------------------
Use `sudo()` to bypass access restrictions for the `final_yearly_costs` field when generating the offer.

opw-5243280

Forward-Port-Of: odoo/enterprise#102250
Forward-Port-Of: odoo/enterprise#99478

In #92208 the CAF system was improved to find the next starting value in the right sequence if there are multiple in the system. If no CAFs are found, it will reset to the document types starting number.

This worked except in the case where there are multiple CAFs that are currently marked active in a document type. As it tries to access `caf.start_nb` it hits an ensure_one() which throws a traceback whenever you open most account.moves on the DB.

Steps to reproduce:
- Modify the CAF for Doc Type 33 (Electronic Invoices) to have a smaller range than 1 - 999,999 (1 - 5)
- Create Two new CAF files also for Doc Type 33 that start after this value (6 - 10 and 11 - 15 for example).
- Mark the original to be spent via cancelling it and try to open an invoice. It will find both of the new CAFs and try to get the start_nb of the recordset.

In discussion with the PO, when we have multiple CAFs, we should pick by the lowest start number as it will allow for any gaps that might exist be filled.

opw-5414350

Forward-Port-Of: odoo/enterprise#102385

**BUG:** 
Traceback when **suggesting** deleting a BOM step from the shopfoor. 

**STEPS TO REPRODUCE:** 
- Open a shopfloor MO (with PLM installed)
-- Add a suggestion step (MO > cog> Update instructions > Improvement Suggestion > Add a step). 
-- Add a second suggestion step after the first one.
-- Delete the second suggestion step  (MO > cog> Update instructions > Improvement Suggestion > Delete a step).
-- Add a third suggest suggestion step after the second one we just suggested deleting.
-- > Traceback 

**ORIGIN:** 
First, when adding the suggestions:
 - 2 Quality Check (QC) are created on the **new_bom_id** in `add_quality_check_from_tablet.save()` 
 - 2 Quality Point (QP) are also created in  `add_check_in_chain()`, (only in mrp_workorder_plm override) 
- The 2nd new QC is linked to previous QC in `_insert_in_chain`

Secondly, when deleting the 2nd added suggestion (_on the same MO, as suggestions are linked to the new bom_id and wont appear on other MOs until ECO is validated_):
- The QP of the second QC is deleted (but the QC itself is not deleted) here:

https://github.com/odoo/enterprise/blob/f91b0c8c41f40a71cbea3cd4f5ccc6873af3c004/mrp_workorder_plm/wizard/propose_change.py#L72-L74

Finally, when adding a new suggestion after the one we just suggested deleting, in `_add_check_in_chain`, a traceback happens by trying to access the QP point we deleted in the resequencing part of  `_add_check_in_chain` here:
https://github.com/odoo/enterprise/blob/eb716c18944ec50c9c8c74a2888ed5f3032a7b08/mrp_workorder_plm/models/mrp_workorder.py#L62-L63

**FIX:**
We accept that not all QCs must have QPs  `[0]` -> `[:1]` (see note on another approach idea) changing

```diff
- point = check.point_id if check.point_id.operation_id == operation else points.filtered(lambda p: p._get_sync_values() == check.point_id._get_sync_values())[0] 
+ point = check.point_id if check.point_id.operation_id == operation else points.filtered(lambda p: p._get_sync_values() == check.point_id._get_sync_values())[:1] 
```

**NOTES:**
-1 Another fix could have been to delete the QC at the same time as the QP but I did not find any `remove_from_chain` function to safely remove the QC from the chain of QC. Along those lines we could rethink the sequencing / resequencing of QC and QP as the logic seems to differ between both. 
-2 Added some comments to remove the field and the line setting the `is_deleted` field in master as it was not used anywhere in the code (the color highlighting in the ECO is done with `<list decoration-danger="change_type=='remove'" ...>`)

Upgrade PR: https://github.com/odoo/upgrade/pull/9076
ticket #5180122

Forward-Port-Of: odoo/enterprise#101366

Prior to this commit, when the AI action prompt was left empty, we would get a traceback when that AI action was executed. The traceback would occurs because the prompt is an HTML field with the field selector plugin, which means that it requires parsing before it's sent to the LLM. There was no check during parsing whether the field is empty or not and thus a traceback would occur during processing.

In this commit we added a check for whether the prompt field is empty or not and if it is, we skip parsing altogether. We still call the LLM but without the final-prompt. The pre-prompt with contextual information is still sent thus the LLM can still perform the action if it's simple enough.

Also, if the AI server action prompt is ambiguous and the LLM "feels" like it needs additional input to complete its task, it might respond with an additional query to the user instead of calling one of its available tools.

Thus, in this commit, we add an explicit instruction to the AI Server action pre-prompt which should convey to the LLM that it will not be able to get any additional input from the user and it should assume that any important information for performing its task will be hardcoded in its available tools.

Task-5379758

Forward-Port-Of: odoo/enterprise#102441

When refunding an order that originally had a global discount, if you didn't refund the discount, the refund total amount would exceed the original order total. This would cause issues when trying to generate a global invoice for the mexican localization.

Steps to reproduce:
-------------------
* Activate the global discount option in any PoS
* Open PoS and make a sale with a global discount
* Refund the sale without including the discount
* Go to the backend
* Go to the order list and select the 2 orders you made
* Now try to create a global invoice
> Observation: The global invoice is in error because the negative lines
  cannot be distributed correctly.

Why the fix:
------------
To avoid this issue with the global invoice we simply prevent the user to generate a refund with a greater amount than the original order. We only apply this limit to the mexican localization because it's the only module that is affected by this issue. Other localizations can still refund without restrictions even if this work flow does not really make sense.

opw-4899501

Forward-Port-Of: odoo/enterprise#101752
Forward-Port-Of: odoo/enterprise#93101