Steps to reproduce:
----------------------------------------
1. Install the Recruitment module
2. Navigate to Recruitment > Applications > All Applications
3. Go to Kanban view
4. Make any application Very High Priority (3 star)
5. Refresh the page

Observation:
----------------------------------------
Applications marked as Very High Priority are not displayed on top, Applicants with higher priority should be displayed first within the same stage.

Issue:
----------------------------------------
The `_order` attribute on the applicant model is declared twice, causing the intended priority-based ordering to be overridden by `sequence`. https://github.com/odoo/odoo/blob/6fed805389d878558e4139b270ee7a70269af767/addons/hr_recruitment/models/hr_applicant.py#L28-L41

Solution:
----------------------------------------
Reorder the fields in the `_order` attribute so that priority is applied before sequence, ensuring higher-priority applicants are shown first

opw-5893371

Forward-Port-Of: odoo/odoo#247779

Issue before this commit:
=========================
When opening a Barcode Rule form view, a traceback was raised due to the following
python expression: bool(parent.is_gs1_nomenclature or type == 'alias')

Steps to Reproduce:
=========================
- Install the stock module.
- Go to Configuration → Barcode Nomenclatures in the Stock app.
- Open any Barcode Nomenclature form.
- Go to the Rules tab and open a rule (pop-up form view).
- Click on the Expand button.
- A traceback is raised.

Cause of the issue:
=========================
The form view tries to evaluate `parent.is_gs1_nomenclature`, but the `parent` record
is not defined when the rule form view is opened directly (via expand), leading to a traceback.

This happens because the form view is not defined as a child of any parent view,
so no parent context is available, which leads to a traceback.

With This Commit:
=========================
Removed the usage of `parent.is_gs1_nomenclature` and use `is_gs1_nomenclature`
directly instead. The `is_gs1_nomenclature` field on `barcode.rule` is already a
related field to `barcode.nomenclature`, so it can be safely used without relying on the parent.

opw-5949083

Forward-Port-Of: odoo/odoo#249293

Steps to reproduce
=================
1. Go to “View all activities”.
2. Switch to calendar view.
3. Click on an activity not linked to any model
(e.g. “Eat cookies”, “Send Email to Alfred”).
4. Click “View” in the popover.
=> Traceback

Reason
======
The commit [1] allow activities without a linked model and from commit [2]
such activities can be opened in the activity form view.

In the calendar view, the action is retrieved from the model and executed
using `doAction`. Since the action does not define `views`, and the `doAction`
depends on `action['views']`, an error occurs when the action service attempts
to copy it.

After this commit
==================
This commit fixes the issue by modifying the action returned from `action_open_document`
for non-linked models to include `views`, similar structure used when a model is present.

[1] https://github.com/odoo/odoo/commit/165b060473be8a5d33d62d311f0dc55ed6332d69
[2] https://github.com/odoo/odoo/commit/abeac135b9bb7aec4bcddd84fb0705743297f80d

Task-5857887

Forward-Port-Of: odoo/odoo#246442

Issue:
-------
When a zero price product is created and the contact us button on the product page is intended to redirect to some snippets created through drag and drop then the button doesn't work as intended meaning it doesn't redirects to the desired snippet even after putting the correct anchor.
for ex: `#snippet-anchor` in the `Button URL` field in the settings.

Cause:
--------
This works fine for the pages having '/contactus' or '/'. Issues raise only when we try to redirect to a snippet. Now, if the we try to redirect to any snippet on click of the button(Contact Us) by placing the corresponding anchor, it will not redirect/work as intended. This is because of the appending`?subject=product_name` that took place.

Solution:
------------
To concatenate the `subject=product_name` conditionally if the url has '#' in it If yes, we just use the `url` in the URL so that it redirects as intended else concatenate the subject & so on.
This is because for redirecting to snippets we use anchors such as '#Let's-Connect'. So, In an anchor the '#' will definitely reside.

Steps to reproduce:
-----------------------
1. Create a db in version 18.3 with website_sale installed.
2. Enable the `Prevent Sale of Zero Priced Product` checkbox in the settings.
3. Create a zero price product and few snippets under it and copy the anchor of one of the snippets to redirect when clicked on the 'Contact Us' button.
4. Use the Anchor(for ex: '#Let's-Connect') in the 'Button URL' field of settings.
5. Navigate to the created product and click on the 'Contact Us' button. Nothing happens & no intended redirection to the desired snippet.

Ref PR:
----------
https://github.com/odoo/odoo/pull/189049/changes#diff-39e02d03a8b765b4e3afc68627aeb33f11b587163638fedfb92ed5657c3336e7R398-R399

Attachments:
-----------------
**Before Fix:**
[vokoscreenNG-2026-02-06_17-36-37.webm](https://github.com/user-attachments/assets/a09101d4-13df-415d-a902-420a28aedef0)


**After Fix**:
[vokoscreenNG-2026-02-06_17-38-37.webm](https://github.com/user-attachments/assets/a6256d0f-d8cb-4146-b95e-33452a0a79c5)


- OPW - [5494517](https://www.odoo.com/odoo/project/70/tasks/5494517)


---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#247587

### Issue:

The action used in the ` timesheet approval reminder` email template refair to a non existing action.

### Cause of the issue:

The issue has been introduced in [1](b56e355c400c874f7cd9c3174e2253ad5769a461) b56e355c400c874f7cd9c3174e2253ad5769a461

Starting from 17.3 the actions `action_timesheet_previous_week` and `action_timesheet_previous_month` have been removed and merged in a single action `timesheet_grid_to_validate_action`. See [2](7040535ffe2c08d0d286cfccbaf4cc7f81f18443) 7040535ffe2c08d0d286cfccbaf4cc7f81f18443 However, while [2](7040535ffe2c08d0d286cfccbaf4cc7f81f18443) correctly replaced the usage of both actions used in the template as `action_xml_id`:
https://github.com/odoo/enterprise/blob/913418bb3d7558b6b44916455e28de855eb123f5/timesheet_grid/models/res_company.py#L209-L221 https://github.com/odoo/enterprise/blob/913418bb3d7558b6b44916455e28de855eb123f5/timesheet_grid/data/mail_template_data.xml#L43-L45

The forward port of [1](b56e355c400c874f7cd9c3174e2253ad5769a461) replaced it with the deleted action:
https://github.com/odoo/enterprise/blob/913418bb3d7558b6b44916455e28de855eb123f5/timesheet_grid/models/res_company.py#L161-L171 https://github.com/odoo/enterprise/blob/913418bb3d7558b6b44916455e28de855eb123f5/timesheet_grid/models/res_company.py#L193-L198

opw-5890269

Forward-Port-Of: odoo/enterprise#107440
Forward-Port-Of: odoo/enterprise#107385

Description:
-----------
When viewing planning shifts in the gantt view, the total hours column displayed wrong totals due to timezone
misalignment in work interval calculations.

Steps to reproduce:
-------------------
1. Create an employee with a fixed working schedule (e.g., 8am-12pm, 1pm-5pm with 1-hour lunch break)
2. Ensure the employee's timezone differs from UTC (e.g., Europe/Brussels UTC+1)
3. Create a shift for this employee covering their full working day (8am-5pm)
4. Open the planning gantt view and check the total hours column for that day
5. Expected: 8 hours total | Actual: 7 hours total (with hours misaligned by timezone offset)

Root Cause:
-----------
In version 19.0, `_gantt_progress_bar_resource_id` used `.replace(tzinfo=pytz.UTC)` when building work intervals, which only changes the timezone label without converting the actual time values. This caused a timezone offset mismatch in the frontend's hour-by-hour comparison.

Solution:
---------
Replace `.replace(tzinfo=pytz.UTC)` with `.astimezone(pytz.UTC)` to properly convert datetime values to UTC before sending to the frontend.

opw-5190244

## Short functional explanation of the error
When setting a shift spread on multiple days for an employee who has a flexible schedule and previewing the planning of this employee, on the shown calendar, the color dot doesn't show. Instead, 'null' appears.

## Reproduction Steps
1. Go to planning and create a shift extended on multiple days for an employee who has a flexible schedule.
2. Click Publish and Send.
3. Click on Actions on the left top side and click Preview.
4. Select the employee you just created the shift for.
5. Click on Preview.
6. It opens a window with the employee's planning. On the left top side, click Month.

### Expected behavior
A shift spread on multiple days should show, with a color dot on the left of the schedule.

### Unexpected behavior
Null appears instead of the color dot. Moreover, the background of the shift has the color of the color dot that should be there.

## Origin of the issue
For employees with specified working schedules, multiple-days shifts are limited to their schedule. Thus, these shifts are split on the working hours of the employee.
But flexible employees have no specified working hours, so the shifts aren't split. This creates multiple day slots. FullCalendar generates different html codes for such slots, which don't contain class ```fc-daygrid-event-dot```, responsible for the creation of the color dot next to the shift schedule. However, even if this color dot isn't created, we still mention it here:
https://github.com/odoo/enterprise/blob/59cec3e8c6a0880178aa93651dca66c367d36841/planning/static/src/js/planning_calendar_front.js#L116 to display shifts. Therefore, we have to create it if it doesn't exist.
__
opw-5437257

1. Create a contact (with minimal details).
2. Create a customer invoice for that contact **last month** with `quantity = 300`.
3. Create a credit note for that invoice **this month**.
4. Create another customer invoice for the same contact **this month** with `quantity = 100`.

In the FAIA report (XML), within the General Ledger section, the partner is incorrectly classified as a supplier instead of a customer.

In the method _saft_fill_report_partner_ledger_values from account_saft, he partner type is determined based on whether the balance is negative.

However, a negative balance can result from a credit note, where the partner is still a customer and not a supplier. Furthermore, a partner can be both a supplier and a customer.

This commit allows a partner to be both a customer and a supplier. If both receivable and payable are 0 we set the partner type to customer to keep the behavior from e9640caf29e967fe7d8c6fe303b5a8d7a866437e

opw-5360924

Forward-Port-Of: odoo/enterprise#106315
Forward-Port-Of: odoo/enterprise#100749