Problem:
Users cannot change analytic distribution set on employees. Users encounter an error when trying to change it.

Steps to reproduce:
1. Enable analytic accounting
2. Try to edit the analytic distribution field on an Employee
3. Notice the error being thrown when trying to save

Cause:
Analytic distribution field is a JSON field and JSON field and tracking is not supported on JSON fields.
https://github.com/odoo/odoo/blob/2aa35eb9c7a709126dca65e81ca6e823706fbb19/addons/mail/models/mail_tracking_value.py#L172
Tracking is supported for other fields but is not supported for JSON fields, so setting tracking=True on a JSON fields leads to an error being thrown. The error gets thrown whenever the field is edited.

Caused by 88a3e70 , as a result of this comment
https://github.com/odoo/odoo/blob/0133e46f89df7dce8c39d2bacd29579d57a83fad/addons/hr/models/hr_version.py#L443

that mentioned that whitelisted fields should have tracking set to true.
However, that's not necessary.

opw-6405122

Forward-Port-Of: odoo/enterprise#125135

## [FIX] timesheet_grid: remove duplicate rpc call

Before this commit, the `loadTimesheets` method is called 2 times in a
row, that method does a rpc call to load the existing timesheets and so,
it is not needed to call it 2 times since the rpc will return the exact
same result.

This commit removes the rpc call when we compute the suggestions to only
load the timesheets when we load all the data.

## [FIX] timesheet_grid: show chronological view instead of project view

Before this commit, the `by project` view were loaded first in the
timesheet assistant action, to group the suggestion by project, the
problem is at the beginning the view will not really show a perfect
matching and so the user could think the feature does not work and he
will not understand how to correctly match the suggestions shown in the
view.

This commit changes the view loaded by default in Timesheets Assistant
to first show the chronological view, that view is more logical for the
current user to rethink what he did in the past to correctly map the
events to a project and a task when he generates his timesheets thanks
to those events. The by project view is still useful afterwards when the
system has learned the choices made by the current user.

## [FIX] timesheet_grid: ensure events are consumed forever

Before this commit, the suggestions removed by the current user comes
back when he changes the date and come back to the day he removes the
suggestions. The reason is because a shallow copy of events consumed is
made and that copy alters the duration of the initial object.

This commit avoids copying the consumed events object to make sure the
initial object is not altered when processing the events to remove them
if they are removed before by the user.

### Steps to reproduce the issue:

1. install timesheet_grid and Activity watch, makes sure Activity watch
collects some activities on your computer.
2. Go to Assistant menu in timesheets app.
3. Remove some suggestions displayed in the right panel.
4. Go to next date.
5. Come back to previous date.

### Expected Behavior:


The suggestions removed should not appear again.

### Actual Behavior:

The suggestions removed come back in the view.

## [FIX] timesheet_grid: fix flicker when suggestion selected

Before this commit, when the user selects a suggestion in timesheet
assistant, there is a small flicker appears because the height of the
row grows because of the border added to highlight the suggestion
selected.

This commit reviews a bit the style to make sure the border bottom in
the previous element is removed if the element is not selected or if the
2 consecutives suggestions are selected.

## [FIX] timesheet_grid: fix discord rules to handle discord in web

Before this commit, when the user uses discord in its browser instead of
the app on his computer, the discord rules don't catch the activity
watch events because the tab title is different than the windows name in
the app.

This commit adapts the regex of Discord rules to handle the both use
cases.

task-[6385639](https://www.odoo.com/odoo/project.task/6385639)

Problem:
Users cannot change analytic distribution set on employees. Users encounter an error when trying to change it.

Steps to reproduce:
1. Enable analytic accounting
2. Try to edit the analytic distribution field on an Employee
3. Notice the error being thrown when trying to save

Cause:
Analytic distribution field is a JSON field and JSON field and tracking is not supported on JSON fields.
https://github.com/odoo/odoo/blob/2aa35eb9c7a709126dca65e81ca6e823706fbb19/addons/mail/models/mail_tracking_value.py#L172
Tracking is supported for other fields but is not supported for JSON fields, so setting tracking=True on a JSON fields leads to an error being thrown. The error gets thrown whenever the field is edited.

Caused by 88a3e70 , as a result of this comment
https://github.com/odoo/odoo/blob/0133e46f89df7dce8c39d2bacd29579d57a83fad/addons/hr/models/hr_version.py#L443

that mentioned that whitelisted fields should have tracking set to true.
However, that's not necessary.

opw-6405122

Forward-Port-Of: odoo/enterprise#125135

While trying to fix the SAT cron, we did not think it through
it could cause infinite cron triggering.
Indeed, the write_date is updated on every record that is handled.

Fix is manyfold:
- Avoid re-processing what we already check within the last 4 hours/12 hours
depending on the type of the document.
- The domain takes the *static* create date instead of the write_date
to make sure we don't endless re-process the same record and that
the window of 7/60 days applies.
- Limit the Vendor Bill to be checked only during 7 days after their creation.
- Use the create_date in the order of the search to ensure we process older
records first, before their time-window closes.
- Process the Vendor Bills last, this ensure Customer Invoices will be processed
in priority in case we are not able to process everything within the last 4/12 hours.

This is still imperfect and a little fragile, we will find a better solution
in master, most likely by adding a dedicated field to keep track of the
last SAT check.

See https://github.com/odoo/enterprise/pull/123213
See https://github.com/odoo/enterprise/pull/103272

task-none

Forward-Port-Of: odoo/enterprise#125317

While trying to fix the SAT cron, we did not think it through
it could cause infinite cron triggering.
Indeed, the write_date is updated on every record that is handled.

Fix is manyfold:
- Avoid re-processing what we already check within the last 4 hours/12 hours
depending on the type of the document.
- The domain takes the *static* create date instead of the write_date
to make sure we don't endless re-process the same record and that
the window of 7/60 days applies.
- Limit the Vendor Bill to be checked only during 7 days after their creation.
- Use the create_date in the order of the search to ensure we process older
records first, before their time-window closes.
- Process the Vendor Bills last, this ensure Customer Invoices will be processed
in priority in case we are not able to process everything within the last 4/12 hours.

This is still imperfect and a little fragile, we will find a better solution
in master, most likely by adding a dedicated field to keep track of the
last SAT check.

See https://github.com/odoo/enterprise/pull/123213
See https://github.com/odoo/enterprise/pull/103272

task-none

Forward-Port-Of: odoo/enterprise#125317

While trying to fix the SAT cron, we did not think it through
it could cause infinite cron triggering.
Indeed, the write_date is updated on every record that is handled.

Fix is manyfold:
- Avoid re-processing what we already check within the last 4 hours/12 hours
depending on the type of the document.
- The domain takes the *static* create date instead of the write_date
to make sure we don't endless re-process the same record and that
the window of 7/60 days applies.
- Limit the Vendor Bill to be checked only during 7 days after their creation.
- Use the create_date in the order of the search to ensure we process older
records first, before their time-window closes.
- Process the Vendor Bills last, this ensure Customer Invoices will be processed
in priority in case we are not able to process everything within the last 4/12 hours.

This is still imperfect and a little fragile, we will find a better solution
in master, most likely by adding a dedicated field to keep track of the
last SAT check.

See https://github.com/odoo/enterprise/pull/123213
See https://github.com/odoo/enterprise/pull/103272

task-none

Forward-Port-Of: odoo/enterprise#125317

### Problem
`pos.config.get_limited_products_loading` orders candidate products by `is_favorite`, service type, last `stock.move.line` date and `write_date`, with no final tiebreaker:

    ORDER BY product_product__product_tmpl_id.is_favorite DESC,
             CASE WHEN product_product__product_tmpl_id.type = 'service' THEN 1 ELSE 0 END DESC,
             pm.date DESC NULLS LAST,
             product_product.write_date DESC
    LIMIT %s

When several candidate products tie on all of those keys — e.g. non-favorite consumable products with no stock moves, created within the same transaction and therefore sharing an identical `write_date` (`transaction_timestamp()`) — the `LIMIT` result is decided by PostgreSQL's unspecified physical scan order. The set of products loaded into the POS session is therefore non-deterministic: which products load can change between runs depending on physical row layout, even though the data is identical.

This is observable as intermittent failures of tests that assert on the limited-loaded product set (e.g. `pos_loyalty`'s `test_product_loading`), passing or failing on scan order rather than on any real data difference.

### Fix
Add `product_product.id` as a final ascending tiebreaker so limited product loading is stable and reproducible. Among products of otherwise-equal loading priority, the lower-id (established) products load first.

### Test
Adds a `TransactionCase` (`point_of_sale/tests/test_pos_product_loading.py`) that creates several products tying on every ORDER BY key and asserts the lowest-id ones load deterministically once the limit is reached.

**Problem:**
When creating a new task, the Customer does not follow the project the user selects: once a first project has filled it, selecting another project keeps the previous project's customer.

**Steps to reproduce:**
1. Create a new task and select a project that has a customer.
2. The Customer is set to that project's customer.
3. Select another project configured with a different customer.
4. Observe the Customer keeps the first project's customer.

**Current behavior:**
The Customer keeps the first selected project's customer.

**Expected behavior:**
The Customer follows the selected project and shows its customer.

**Cause of the issue:**
partner_id is filled by _compute_partner_id, which only assigns a partner while the field is empty. Once a project has filled it, selecting another project no longer refreshes the now non-empty Customer.

**Fix:**
Refresh the Customer from the project on project_id change, but only while the task is new (no _origin). An existing task's customer is left untouched, since it may already carry sale order lines, timesheets, materials or worksheets that must not be reset when the project changes.

opw-6315902

Forward-Port-Of: odoo/odoo#276211