__

## Error description
The test fails when it is launched at 23h.
We obtain an assertion error:
`AssertionError: datetime.datetime(2026, 2, 26, 11, 0) != datetime.datetime(2026, 2, 25, 11, 0)`

## Origin of the issue
In the `_default_start_datetime()` method of planning, we return `return datetime.combine(fields.Date.context_today(self), time.min)`. So, we call context_today. which is implemented this way: https://github.com/odoo/odoo/blob/f3ec2aa4514c03874aae96ae975e2617e8260c72/odoo/orm/fields_temporal.py#L154-L158 Let's say the hour of the test is 23h50 in GMT+0. The slot will be created at 23h50 in GMT+0. But if the time zone of the environment is set at GMT+1, at the moment of the `_compute_datetime`, we will call this piece of code, where we will translate 23h50 to GMT+1, we will obtain 00h50, then only return the day, which offsets the result of one day in the future.

X-original-commit: d91c53869842f65a60088ffa101f67404af6e58e

note:
backport of
https://github.com/odoo/enterprise/pull/108891

Forward-Port-Of: odoo/enterprise#110126

Problem:
After https://github.com/odoo/odoo/commit/e809b492c1b138c1af7bb1d4aa61b39d87686df9 typing spaces inside an
"Add to cart" button label in the website editor triggers the button
click instead of inserting a space character.

Cause:
Browsers natively intercept the space key on `button[contenteditable="true"]`
elements and fire a click event instead of inserting the character, making it
impossible to type spaces in the button label.

Solution:
Introduce an `EditableButtonPlugin` that moves the `contenteditable`
attribute from the button up to a wrapping `<span>`. This preserves full text
editing capability (including spaces) without triggering the button's click handler.

Steps to reproduce:
* Go to a product page on the website.
* Open the editor.
* Try to add a space in the "Add to cart" button label.
* Observe that the button is triggered instead of inserting a space.

opw-5994828

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

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#110414
Forward-Port-Of: odoo/enterprise#107760

**Steps to produce:**
- Install the `Accounting` module.
- Enable analytic accounting in settings.
- Create an analytic account (e.g., "test").
- Create a journal entry and assign the analytic account in the analytic
  distribution.
- Post the entry and export it(Make sure `journal items/account` and
  `journal items/analytic distribution` are also included).
- `Archive` the analytic account.
- Import the exported entry `OR` Duplicate the previous created entry.
- Try to post the imported entry.

**Issue:**
- The entry is posted even if the analytic account used in the analytic distribution is inactive.

**Root cause:**
- The `analytic_distribution` field is stored as JSON.
- At [1], the `_str_to_json` method only attempts `json.loads(value)`, and if parsing fails, it raises an error.

**Solution:**
- Add a validation when posting journal entries to ensure that all analytic accounts referenced in the analytic distribution are active.

[1]: https://github.com/odoo/odoo/blob/13e8b462e74f144e085492857bfaa7b0d1f88f93/odoo/addons/base/models/ir_fields.py#L196-L202

opw-5350980

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

Forward-Port-Of: odoo/odoo#244231
Forward-Port-Of: odoo/odoo#239988

The field `res_users.pin` is restricted to members of `hr.group_hr_user` but is added to the form view, so if a user with HR access rights tries to view another user, it will trigger an access error:

```
odoo.exceptions.AccessError: You do not have enough rights to access the field "pin" on Employee (hr.employee). Please contact your system administrator.
```

To reproduce:
- With `hr` installed, remove its access rights from the admin and try to view another user.

This error is related to recent changes[^1] in the access of employee fields, it might be possible to have a different approach to this error. It will break while trying to access the employee field for which the user doesn't have access:
https://github.com/odoo/odoo/blob/012f510e70d7d0afd226e4198b2e1759db3ca18d/addons/hr/models/res_users.py#L29-L36

In earlier versions, the field was not accessed directly. It was just automatically hidden from the view if the user didn't have the right group.
[^1]:https://github.com/odoo/odoo/commit/012f510e70d7d0afd226e4198b2e1759db3ca18d

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