During the work entry apocalypse, the gantt view that was used to do the
exports for Partena, Acerta etc was removed. With it, we lost the
ability to trigger those reports, which we want to reintroduce here. To
do so we create a dropdown element in the cog menu registry, which
starts out empty but is populated with the various reports based on
which modules are isntalled, by inheriting and adding the relative
dropdown items.

At the same time, currently the cogmenu of the employee when hr_presence
is installed is being overridden to use HrPresenceCogMenu which adds a
Dropdown of its own that includes actions related to employee presence.
Therefore, we need to refactor this dropdown becuase depending on the
module installation order the HrPresenceCogMenu might override the
addition of the ExportCogMenu and overriding the CogMenu is not the
correct way to add elements to it in general.

I have been able to move the logic of the PresenceCogMenu to the
registry but the actions don't have the correct context and give errors
because the records are not passed. Also there are some problems with
the ActionMenu (the one that shows up if you select employees from the
lsit view.

Task: 5985900

During the work entry apocalypse, the gantt view that was used to do the
exports for Partena, Acerta etc was removed. With it, we lost the
ability to trigger those reports, which we want to reintroduce here. To
do so we create a dropdown element in the cog menu registry, which
starts out empty but is populated with the various reports based on
which modules are isntalled, by inheriting and adding the relative
dropdown items.

At the same time, currently the cogmenu of the employee when hr_presence
is installed is being overridden to use HrPresenceCogMenu which adds a
Dropdown of its own that includes actions related to employee presence.
Therefore, we need to refactor this dropdown becuase depending on the
module installation order the HrPresenceCogMenu might override the
addition of the ExportCogMenu and overriding the CogMenu is not the
correct way to add elements to it in general.

I have been able to move the logic of the PresenceCogMenu to the
registry but the actions don't have the correct context and give errors
because the records are not passed. Also there are some problems with
the ActionMenu (the one that shows up if you select employees from the
lsit view.

Task: 5985900

Issue
-----
When there are 2 lines for a single product and different packaging uoms, scanning a packaging barcode alternates between lines.

Steps to reproduce
-----
- Enable packagings
- Create a product AAA
	- barcode 1
- Create a packaging 6-Pack
	- 6 units
	- barcode for AAA set to 6
- Create a PO
	- one line for 30 units of AAA
	- one line for 5 6-Pack of AAA
- Confirm PO and open picking in barcode
- Scan "6" multiple times

> Quantity increases on both lines, alternating for each scan

Cause
-----
Both lines can be found as matching lines when doing

https://github.com/odoo/enterprise/blob/d279632db25713dd639a51385cad197dfdbd2bdc/stock_barcode/static/src/models/barcode_model.js#L1426

The reason it alternates between the lines is because we set the currently selected line first in the array - and since both lines match, the `foundLine` returned ends up being the non-selected line.

https://github.com/odoo/enterprise/blob/d279632db25713dd639a51385cad197dfdbd2bdc/stock_barcode/static/src/models/barcode_model.js#L1823-L1832

We can avoid this y refining the `break` condition of the loop to also match the packaging uom.

-----
Ticket:
opw-6034572

Forward-Port-Of: odoo/enterprise#112578

When the network drops after eTIMS processes a transaction but before Odoo receives the confirmation, Odoo would retry with the same invoice number, causing eTIMS error 924 (Invoice number already exists).

For POS orders, the old code decremented the sequence on any error (including timeout), so the next retry consumed the same invcNo. If eTIMS had already recorded the original send, the retry was rejected with 924. Fix by introducing a fetch-first strategy: on retry, if a pending invcNo is found in l10n_ke_order_json, call selectInvoiceDetails before sending. If eTIMS already has the invoice, recover the receipt data directly without resending. If eTIMS does not have it, resend with the same invcNo safely. On timeout errors, the sequence is no longer decremented so the invcNo is preserved in l10n_ke_order_json for the next idempotent retry.

For customer invoices, the existing fetch-first logic only bailed out on TIM (timeout) errors, falling through on CON (connection) errors and retrying blindly. Additionally, if saveTrnsSalesOsdc returned 924, there was no recovery path and the invoice number would be cleared. Fix by also bailing on CON in the fetch block, and adding an explicit 924 handler that calls selectInvoiceDetails to recover the existing receipt instead of failing.

opw-6105693

Forward-Port-Of: odoo/enterprise#115649

**Steps to reproduce:**
- Create a new marketing campaign with two activities
- Set them to occur some number of days after the beginning
- Save the campaign and start it
- Modify one of the activities to occur some number of days after the
other activity and save
- Modify the child activity by changing the number of days after its
parent that it should run and save
- An error will be thrown

**Issue:**
The trace related to the child activity has no parent when trying to reschedule it in `_update_schedule_date`. This causes an issue when trying to get the first mailing_trace_ids using index 0 in this line:
`base_dt_str = trace.parent_id.schedule_date or trace.parent_id.mailing_trace_ids[0].write_date or trace.participant_id.create_date`

**Fix:**
Prevent the activity hierarchy to be modified on started campaigns.
We also change the indexing to avoid further out of range issue and
properly default on the participant create value.

Trying to match existing traces to their parents has too many edge cases when trying to avoid duplicates, and might often need to reset the whole trace chain to work properly. This approach avoids user mistakes on running
campaigns, but if a user tries to launch a test (even on draft campaign) he won't be able to modify the hierarchy further without deleting/recreating some activities/traces. So we should ignore this for test traces, but it could
impact the behavior between test and actual executions.

opw-5362978

Forward-Port-Of: odoo/enterprise#107556

__

## Short functional explanation of the error
When for an employee with a Flexible schedule, we set a shift overlapping on two days. The attendance report displays twice the worked hours.

## Reproduction Steps
1. Create an employee with a flexible schedule and with Work Entry Source set at Planning.
2. Go to Planning. Create a Planning Slot for this employee from 9 pm to 5 am, then Send and Publish it.
3. Click on the Reporting tab > Planning / Attendance Analysis.

### Expected behavior
The total for this Month for this employee under the Planned Time field should be equal to 8 hours, which is the duration of the planning slot.

### Unexpected behavior
The total for this Month for this employee under the Planned Time field is equal to 16 hours.

## Origin of the issue
This report is a view, for which the SQL is defined starting this line: https://github.com/odoo/enterprise/blob/7362f1c5be7f496bdab660ed8fad37a6dd283616/planning_attendance/report/planning_attendance_analysis_report.py#L27 the issue stems from here:
https://github.com/odoo/enterprise/blob/7362f1c5be7f496bdab660ed8fad37a6dd283616/planning_attendance/report/planning_attendance_analysis_report.py#L56 where we don't select distinct the planning entries based on their ID. As our shift overlaps 2 days, there will be only one entry for this shift in the `planning_slot`, but because of that, it will be duplicated.

__
opw-6146052

Forward-Port-Of: odoo/enterprise#115447

## Issues
When starting a timer from a task within a project, the timer appears in two locations: the page header, and the task's *Timesheets* tab. The latter does not behave as expected: when opening the *Timesheets* tab,
the timer resets to 00:00, and if the timer was started more than a minute earlier, it begins counting down (00:00, then -00:59, and so on). (**I1**)

A second issue (**I2**), introduced at the same time, is that two timers can run simultaneously if the database is reloaded while a timer is active.

A third issue (**I3**) happens after starting and stopping a timer from the Project app: the timer seems to still be running in the Timesheet app.

## Steps to reproduce
1. Install *Timesheets* (`timesheet_grid`)
2. Create a Project P and a Task T
3. Start the timer for Task T, wait a few seconds, then open the *Timesheets* tab
4. **The timer from the _Timesheets_ tab does not match the one on top of the page**
5. Wait for the timer in the header to reach 00:01:00, then open the *Timesheets* tab again
6. **The timer is going backward**

For the second issue (**I2**), after executing the steps above:
7. Do not stop the timer, but stop the database and start it again
8. Create a new Project P2 and a Task T2
9. Start the timer for Task T2
10. **The timer in the header blinks between the timer from T1 and the newly started timer for T2**

![5879176](https://github.com/user-attachments/assets/d9be8b8c-8973-4790-80a5-6f291f0b766a)

For the third issue (**I3**):
1. In the project app, (create a project and a task and) start then stop a timer. Log the time
2. Open the timesheet app
3. **A timer is running**

## Cause
The issues are introduced by the following commit: https://github.com/odoo/enterprise/commit/f4c7115fdf.
The commit aimed to resolve an issue in which timers for sample data would start automatically, and the *Stop* button would throw an error. The issue was addressed by updating the condition that defines the `timerRunning`
variable, which controls whether the *Stop* button in the Timesheets app is displayed.

https://github.com/odoo/enterprise/blob/ac186aa71cd7e1b80b307ea12c7eaca246afd649/timesheet_grid/static/src/components/timesheet_display_timer/timesheet_display_timer.js#L57-L64

Issue **I1** is a side effect of this change in the Project app, where the `timerRunning` variable is evaluated to `true`, causing the timer to be displayed when it should not.

The multiple timers running simultaneously (**I2**) stems from the `timerRunning` variable being initiated to false by default in the props.

https://github.com/odoo/enterprise/blob/64f813dab727d76286c1ff6c80c08cb6a6737b49/timesheet_grid/static/src/components/timesheet_display_timer/timesheet_display_timer.js#L47-L50

The *Stop* button appearing after logging a task (**I3**) stems from the condition of the patch using `is_timer_running` over `timer_start`.

https://github.com/odoo/enterprise/blob/64f813dab727d76286c1ff6c80c08cb6a6737b49/timesheet_grid/static/src/hooks/sample_server_patch.js#L9-L15

## Fix
This commit reverts the problematic segments from the previous commit.

opw-5870756
opw-5879176
opw-5961764

Forward-Port-Of: odoo/enterprise#107014

Steps to reproduce:
------------------------------------
1. Install Timesheets Module with demo data
2. Create a new Employee with: 
    * Payroll Page > Contract > Start from 1st March
    * Payroll Page > Working hours set to 'Standard 40 hours/week'
3. Go to Timesheets > All Timesheets
4. Add Timesheet for any task as follows:
    * Select a date in a past week (e.g., 14th April)
    * Hours: 8 hours
    * Select the newly created employee
5. Go to Timesheets > All Timesheets:
    * Filter by the new employee
    * Navigate to the same past week
    * Observe the remaining hours for the employee (e.g, -32:00)
6. Open the newly created employee form:
    * Click on '+' to create a new contract version
    * Set the version date before the timesheet date (e.g., 12th April)
    * Change Working Hours to Standard 38 hours/week.
7. Repeat Step 5

Observation:
------------------------------------
The Remaining Hours shows -32:00, meaning the system still uses the 40 hours/week schedule instead of the updated one. The expected value should be -30:00 based on the 38 hours/week schedule.

Issue:
------------------------------------
The method `_get_contracts_valid_periods` determines which working calendar applies for which time period. It uses `contract.contract_date_start` and `contract.contract_date_end` to build calendar validity intervals, but these are the contract employment dates (shared across all versions of the same contract), NOT the version-specific effective dates.
Both versions share the same `contract_date_start`, so both claim the entire period as valid. The 40h calendar produces larger work intervals that win when combined via Intervals union, so the old 40h schedule is used instead of the current 38h one.

Solution:
------------------------------------
Replace `contract.contract_date_start` / `contract.contract_date_end` with `contract.date_start` / `contract.date_end`
These dates represent each version's effective validity period, computed from `date_version` and bounded by the next version's start date. Using these ensures each calendar is only valid during the period its version was actually in effect correctly splitting the working hours at version boundaries.

opw-6142137

Forward-Port-Of: odoo/odoo#264114
Forward-Port-Of: odoo/odoo#260614