Steps to reproduce:
-------------------------------------
1. Install the Subscription module.
2. Go to Subscription > Configuration > Recurring Plans.
  * Open a Monthly recurring plan and enable Align to Period Start.
3. Create a new Subscription:
  * Select the configured monthly plan.
  * Add any subscription product.
  * In the Other Info tab, set a Start Date in the past on the 1st day of a month (e.g., 01/11/2025).
4. Confirm the subscription.
5. Create a draft invoice.

Observation:
-----------------------------------
In the invoice line, you see the message:
`61 days 11/01/2025 to 12/31/2025`

It should be:
`1 Month 11/01/2025 to 11/30/2025`

Issue:
-----------------------------------
https://github.com/odoo/enterprise/blob/a5a76de5f25483afa5432ed333c48d78832f128c/sale_subscription/models/sale_order_line.py#L376-L378 In `_get_invoice_line_parameters`, the computation attempts to find the next 1st day of the month However, `new_period_stop` already includes the billing period. When `new_period_stop` is in the past, an extra month is added through `new_period_stop + relativedelta(months=1)`, resulting in an incorrect period range

Solution:
-----------------------------------
Use `new_period_start` as the anchor point for period computation. Ensure the billing period ends on the last day of the starting month when Align to Period Start is enabled

For upsell orders, the fix is NOT applied because for upsells, `new_period_stop`
is already set to the parent subscription's `next_invoice_date`, which
represents the correct billing boundary.

opw-5920036

Forward-Port-Of: odoo/enterprise#107407

Steps to reproduce:
----------------------------------------
1. Install the `hr_recruitment` module
2. Create a new user and configure the following access rights:
    * Employees: No
    * Recruitment: Officer Manage all applicants
3. Create new job position > Set created user in Recruiter
4. Log in with the created user
5. Go to Recruitment > Click on the Configure button of that job position

Observation:
----------------------------------------
The Trackers page is not visible on the job position form for the recruitment officer user.
If the user is additionally granted the Employees → Officer: Manage all employees group, the Trackers page becomes visible. The access to the recruitment Trackers should not depend on the Employee 'Officer: Manage all employees' access right.

Issue:
----------------------------------------
The visibility of the Trackers page depends on the Employees → Officer: Manage all employees group instead of the recruitment officer access rights

Solution:
----------------------------------------
Grant access to the Trackers page using the Recruitment Officer group so recruitment officers can access it without requiring the employee officer privileges

opw-5969416

Forward-Port-Of: odoo/odoo#252209

**Steps to reproduce:**
- Set up an event, go put it's state to Annonced
- Set up any online payment method (Demo also triggers the bug)
- Go to a PoS that sells the event tickets
- Purchase one and pay with the online payment method
- Once on the ticket screen, the button to download the event tickets is not displayed

**Why the fix:**
The normal flow only works for offline payment methods, because we check if the ordered is either paid or invoiced before setting all the values needed by the frontend regarding the ticket registration.

The problem is that with an online payment method, once we enter the **read_pos_data** method that sets
the values for the frontend, the order is still in draft, so we just return without doing anything.

We now set the values regardless of the order's status and send the confirmation mail in the same way as if it was an online payment.
In the case of an online payment, the mail will be sent by the **action_pos_order_paid** function that is called once the payment is processed.

A test might be a bit weird to make as we don't have a bridge for pos_online_payment and pos_event, and that we would need to mock the server's answer to be able to pay for the online payment and check that we have the needed values. So the setup for pos_event would have to be copied into pos_online_payment to test it and it would only be ran if both modules are installed.

opw-5438432

Forward-Port-Of: odoo/odoo#258986
Forward-Port-Of: odoo/odoo#249306

**Description of the issue/feature this PR addresses**:
web_read on x2many fields can reuse cached ids after write/web_save. Some of these cached ids may be inaccessible with the current record rules/context (cache pollution).

**Example**:
- **Context**:
  - Two companies exist: Company A and Company B.
  - Two users exist: User A and User B.
  - User A can only access Company A (company_ids=[A], company_id=A).
  - User B is linked to both companies (company_ids=[A, B], company_id=A).
  - The "res.company" record rule is the standard one: [('id', 'in', company_ids)] (company_ids comes from allowed_company_ids).
  - User A edits User B and saves the form.

- **Steps**:
  - User A performs a web_read to load User B: company_ids contains only Company A.
  - User A performs web_save (write + internal web_read in the same request): cached ids [A, B] are reused and the code attempts to read Company B.

**Current behavior before PR (without fix)**:
After saving a form with an x2many field, web_save calls write and then web_read. In this flow, web_read can include inaccessible x2many ids from cache and raise an AccessError.

**Desired behavior after PR is merged**:
x2many records are re-filtered with current read rules before formatting, and inaccessible ids are removed from values_list.

Forward-Port-Of: odoo/odoo#257517
Forward-Port-Of: odoo/odoo#250904

Steps to reproduce:
1. Create an invoice with a 0% tax (Exempt from VAT, category E)
2. Add two lines with 20% discount and fractional prices:
   - qty=4, price_unit=39.615 and qty=4 with price_unit=0.84
3. Send via Peppol
4. Peppol rejects with: [BR-E-08] VAT category taxable amount shall equal the sum of Invoice line net amounts

The TaxableAmount recalculation in _ubl_get_tax_subtotal_node was only applied for tax category 'S' (Standard Rate). However, Peppol schematron has identical rules for all tax categories: BR-E-08 (Exempt), BR-Z-08 (Zero), BR-AE-08 (Reverse Charge), etc.

When lines have discounts and fractional prices, the individually rounded LineExtensionAmount values can sum to a different total than the tax base_amount. This affects both rounding modes. For 'S' taxes this was already handled, but for 'E' (and others) it caused Peppol rejection.

Remove the 'S'-only filter and match dynamically against the actual tax category code so the recalculation applies universally.

opw-6093243

Forward-Port-Of: odoo/odoo#258909