[FIX] planning_field_service: fix follow-up (round 4)
This commit continues to fix the various issues found due to the
refactoring of Field Service feature to integrate it into planning
instead of being an extension of project.

This commit will:
- fix 'Print' action and ticket to intervention portal access
- always display in range mode for planned dates in planning.slot view
- update billable and non-billable filters to take into account
  `under_warranty` field
- review search view of planning.slot, some filters have been renamed
  and moved.
- use employees instead of resources in portal list (no need to display
  the material resource in the portal views in other words)
- add "Send mail", "Send SMS", "Send Report" and "Add/Remove followers" buttons
  in cog menu of list and kanban views of planning.slot model.
- remove helper in ticket button since it does not bring useful
  information.
- add ticket description on related shift, when the user plans an
  intervention from a helpdesk ticket, the new shift created from that
  action, will have the description of the related ticket inside Note
  field (name field)
- fix display_name, to avoid displaying the field used in the group by
  in the display name since it is a bit redundant
- take into account worksheet set in product as default
- fix some labels, visibility conditions, dates format, group_expand
- add default company of the slot when the user creates a resource from
  the form view of planning.slot model
- show customer preview stat button once the intervention is completed
  and a report is available for that intervention
- update tooltip for employee product to bring more context to explain
  how that new field works.
- make sure the SOL for timesheet is not generated when we complete an
  intervention if the project linked is non billable
- add icon on stat button of timesheet
- make sure the user can only create service product in product field in employee
- show "X Products" button to non sale user in the form view of
  planning.slot
- make project billable and timesheetable by default when the user wants
  to create a new project from the project_id field inside the form view
  of planning.slot model
- hide schedule stat button in the form view of project.task if the task
  is a template or linked to a project template
- update visibility condition of sign in in calendar, to make visible
  for planning manager when the slot is published even if the shift is
  not assigned to that user and the slot is in the past.

task-6009593

Forward-Port-Of: odoo/enterprise#110178

Reset cron restores salary rules from XML values.
If reset-critical fields are omitted in explicit rule definitions, cron can keep
unexpected runtime values instead of restoring intended defaults.

This change does 2 things:
- adds create-time warning for missing reset-critical explicit fields
- backfills existing standard/localization salary rule XML records with those
  fields

Warning scope:
- selector fields: condition_select, amount_select
- amount-dependent: quantity (for fix/percentage)
- property_input technical fields only (kept strict, low-noise)
- excludes cosmetic fields (name/description/section/etc.) to avoid warning
  noise

Example:
 ```
<record id="l10n_au_ote_structure_1" model="hr.salary.rule">
     <field name="category_ids"
       eval="[(6, 0, [ref('l10n_au_hr_payroll.rule_category_ote')])]"/>
     <field name="name">Ordinary Time Earnings</field>
     <field name="code">OTE</field>
     <field name="sequence">20</field>
+   <field name="condition_select">none</field>
     <field name="amount_select">code</field>
     <field name="amount_python_compute">
 ...
     </field>
 </record>
```

Example (amount-dependent quantity):
```
 <record id="some_fixed_rule" model="hr.salary.rule">
     <field name="condition_select">none</field>
     <field name="amount_select">fix</field>
+    <field name="quantity">1.0</field>
     <field name="amount_fix">1000.0</field>
 </record>
```

task-6033101

### Issue before this commit:
When changing the system language, the annual report generated from the accountant_knowledge module was only partially translated. While the index and article titles were correctly displayed in the selected language, the content of each section remained in English. This behavior was also visible in the exported PDF version of the report, resulting in a document where only structural elements were localized while the body text of the report sections was not.

### Steps to reproduce the issue:
1. Install another language than english and switch to that one
2. Install Accounting app and audit modules
3. Go to Accounting > Revision > Annual Report
4. Create an Annual Report and click on it
5. Index is in the correct language but the text inside a title is not

### Cause of the issue:
The issue was caused by a modification in the knowledge_article model where the template_body field definition was changed. In the previous implementation, the field was defined as a Text field with translate=html_translate, which allowed the HTML content of the template body to be extracted and processed by Odoo’s translation system. In the modified version, the field was converted to an Html field without specifying the translate parameter. As a result, the content stored in template_body was no longer marked as translatable, preventing the translation extraction mechanism from generating translation entries for the article body.

### Reason to introduce the fix:
Restoring the translation capability for the template_body field ensures that the full content of the annual report can be localized according to the user’s selected language.

opw-5958383

Steps to reproduce:
--------------------------------
1. Install Subscription module
2. Create a new subscription quotation and confirm it
3. Generate an invoice for the subscription
4. Attempt to cancel the subscription
   * A ValidationError is correctly raised
5. Close the subscription by selecting any close (churn) reason
6. Attempt to cancel the same closed subscription again

Observation:
--------------------------------
The subscription is successfully cancelled even though it already has invoices

Issue:
--------------------------------
In the following code:
https://github.com/odoo/enterprise/blob/9e39b4b85fcb9f6ed5b21b942796b76b8a6eefdb/sale_subscription/models/sale_order.py#L741-L742 The cancellation logic does not check whether a subscription is already churned and still has active invoices

Solution:
--------------------------------
Added an additional condition to prevent cancelling churned subscriptions that still have active invoices

opw-5479719

Forward-Port-Of: odoo/enterprise#109755
Forward-Port-Of: odoo/enterprise#106596

Steps to reproduce:
-------------------------------------
1. Install `hr_appraisal_skills` module
2. Create a new employee and assign at least one skill to the employee
3. Set the Next Appraisal Date to today
4. Go to Scheduled Actions > Appraisal: Run employee appraisal > Run Manually
5. Open the newly created appraisal for the employee

Observation:
-------------------------------------
In the Skills tab, the employee's skills are not populated even though the appraisal is already in the confirmed stage

Issue:
-------------------------------------
When the cron  `_run_employee_appraisal_plans` creates an appraisal, it is created directly in `pending` state via  `create()`. The skill-copying logic only lived in the  `write()` override, which triggers on state transitions from 'new' to 'pending'. Since  `create()` bypasses  `write()`, Employee skills were never copied to cron-created appraisals

https://github.com/odoo/enterprise/blob/451dce92a087086fc3d5d5f610626312f32bcd13/hr_appraisal_skills/models/hr_skills.py#L12-L15

Solution:
-------------------------------------
Add a `create()` override to call `_copy_skills_when_confirmed` when an appraisal is created directly in the `pending` state, ensuring employee skills are properly copied.

opw-5491433

Forward-Port-Of: odoo/enterprise#110601
Forward-Port-Of: odoo/enterprise#107760

## Issue:
When computing the product tree, the system would use `_bom_find` to find the BoM. However, it's possible to have multiple BoM for the same product, and the user should have chosen which BoM he wants to use. `_bom_find` ignores the user configuration in MPS, and simply select the first (oldest) BoM in the list. This means that the components in the MPS would not be correctly updated.

---

## How to reproduce:


https://github.com/user-attachments/assets/c7e6f4d4-332a-4e2b-a40a-1b831daeb6c8


- Create Products FNS & CMP
- Create BoM for FNS without bom line (V1)
- Create BoM for FNS with CMP in bom lines (V2)
- Add FNS to MPS using bom V2
- Set Forecast Qty of FNS to 10 
- => Indirect Demand Qty for CMP is not shown (because it's 0)

---

## Test Result without fix:
```
2026-03-05 15:00:24,601 52396 INFO oes_test_18.0 odoo.addons.mrp_mps.tests.test_mrp_mps: Starting TestMpsMps.test_indirect_multiple_boms ... 
2026-03-05 15:00:24,742 52396 INFO oes_test_18.0 odoo.addons.mrp_mps.tests.test_mrp_mps: ====================================================================== 
2026-03-05 15:00:24,742 52396 ERROR oes_test_18.0 odoo.addons.mrp_mps.tests.test_mrp_mps: FAIL: TestMpsMps.test_indirect_multiple_boms
Traceback (most recent call last):
  File "/home/odoo/Odoo/src/18.0/enterprise/mrp_mps/tests/test_mrp_mps.py", line 1556, in test_indirect_multiple_boms
    self.assertEqual(forecast_cmp['forecast_ids'][0]['indirect_demand_qty'], 10)
AssertionError: 0.0 != 10
 ```

---

OPW-5979738

Forward-Port-Of: odoo/enterprise#110526
Forward-Port-Of: odoo/enterprise#109693