Description:
This PR adjusts the alignment of the `TOTAL` and `CHANGE` labels on the POS receipts by modifying the CSS. Specifically, it changes the `padding-left: 6em` rule to `text-align: start`. The reason for this update is to ensure that the labels are consistently aligned at the start, improving readability and layout in different screen sizes and environments.

Previous behavior:
The `TOTAL` and `CHANGE` labels used excessive left padding (`padding-left: 6em`), which caused misalignment in some cases.
![Screenshot from 2024-10-24 11-32-27](https://github.com/user-attachments/assets/7e1cae6d-cef0-43a5-a0cc-da83091d1f13)


New behavior:
The labels are now aligned to the start using `text-align: start`, resulting in a cleaner and more consistent layout.
![Screenshot from 2024-10-24 11-32-55](https://github.com/user-attachments/assets/8467e68a-c6a8-49da-bead-46be573de4d0)


This change enhances the overall appearance of the POS receipts and maintains consistency across different locales and layouts.





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

Forward-Port-Of: odoo/odoo#185014

Some views use a domain widget to edit/save a domain and use it afterwards in several places where domains must have literals only. Typically, a literal_eval is used to evaluate the (string) domain. Thus expressions like "uid" or "context_today()"" should not be used in those contexts.
Here we introduce an option "allow_expressions" (default False) for the domain field and use it to mark as invalid domains that contain expressions when the option is set to False. A notification is displayed when a domain contains an unwanted expressions.

Since we cannot expect modules like base to be updated, we have to find another system to allow the usage of expressions in the form views for the models ir.filters and base.automation: we simply hardcode those models as allowing expressions. Since for these models, the evaluation of domains is done via safe_eval but with a restricted evaluation context, we also display a notification that alerts the user that the evaluation of expressions (although accepted by the domain field) can fail.

We revert the recent commit https://github.com/odoo/odoo/commit/f95c494c3b86b34f2eaa84ae2a5da0d5b7502269 that introduced potentially problematic calls to safe_eval in order to allow evaluation of expressions.

Forward-Port-Of: odoo/odoo#208876

### Steps to reproduce:

- install fsm_industry
- run any of these tests:
    - test_change_parent_plan
    - test_change_parent_plan_conflict
    - test_change_parent_plan_with_intermediate
    - test_change_plan
    - test_change_plan_conflict
    - test_change_plan_no_conflict
#### > create access right error for the `account.analytic.line` model

### Cause of the issue:

The following three record rules provide the creation of `account.analytic.line` for users related to project or timesheet access rights unless the analytic line it self is linked to a project: https://github.com/odoo/odoo/blob/e7bd20e64e023c279bf574630e2d8c8a45ba2fe2/addons/hr_timesheet/security/hr_timesheet_security.xml#L52-L64 https://github.com/odoo/odoo/blob/e7bd20e64e023c279bf574630e2d8c8a45ba2fe2/addons/hr_timesheet/security/hr_timesheet_security.xml#L66-L76 https://github.com/odoo/odoo/blob/e7bd20e64e023c279bf574630e2d8c8a45ba2fe2/addons/hr_timesheet/security/hr_timesheet_security.xml#L78-L83 Since the analytic module is unrelated to the project module, these tests will inevitably fail.

### Note:

These record rules do not stop the record creation once the account module is installed since the following record rules override the creation access rights for `account.group_account_invoice` users: https://github.com/odoo/odoo/blob/e7bd20e64e023c279bf574630e2d8c8a45ba2fe2/addons/account/security/account_security.xml#L102-L107

Similar issue treated in commit 9d164c1d2cd8e532109b9859ab776fcf2f71d115

### Note 2:

A priori, the same problem would occur if we were to write post install analytic tests for portal users:
https://github.com/odoo/odoo/blob/e7bd20e64e023c279bf574630e2d8c8a45ba2fe2/addons/hr_timesheet/security/hr_timesheet_security.xml#L33-L50

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

Forward-Port-Of: odoo/odoo#208978

**Description of the issue/feature this PR addresses:**
- The contact-us form allows task creation without a project (project_id = None).
These tasks are assigned to odoobot, have no followers, and no project, making
them inaccessible due to ACL restrictions. 

**steps to reproduce**
1. Install website_form_project.
2. Edit the contact-us form submit button.
3. Set action to 'Create a task' and select 'None' for the project.
4. Save and submit the form.

**Observation**
- Tasks created under such configuration are hidden in the UI and trigger access
errors when trying to open them.

![access error](https://github.com/user-attachments/assets/e5688152-d78b-4628-a0bd-d9f58e2ca442)

Desired behavior after PR is merged:
- Making the project field required, the created tasks will now be accessible/visible

[opw-4664601](https://www.odoo.com/odoo/project/49/tasks/4664601)

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

Forward-Port-Of: odoo/odoo#207871

### Steps to reproduce:

- In the settings enable "Rental transfers"
- Create a storable product that can be rented put 10 units in stock.
- Create a rental order for 6 units of that product and confirm it.
#### > The rental forecast turns red and incorrectly shows only 4 units available for rent. In the related Gantt view (accessible via the forecast), the record is red and displays the message: "The product is not available during this period."

### Cause of the issue:

Since commit d3253de24ba5397eaed63948edaaf11e10f34e96, the rental forecast availability has been based on the stock forecast at the start of the rental period. This forecast considers incoming and outgoing stock moves, including those from sales or purchase orders. However, as these moves includes these generated by rental transfers and since the `rented_qty_during_period` was already taken into account by the rental order's them self, commit d3253de24ba5397eaed63948edaaf11e10f34e96 attempted to reconcile these moves with the already computed `rented_qty_during_period`. However, this new computation did not not exclude the transfers generated by the order itself.

### Fix:

We revert commit 053f18ee403c274c9fc57c911ee0bee866523356 and instead reconcile rented_qty_during_period using a simpler computation including the rental order’s own moves.

This approach takes advantage of the `ignored_soline_id` parameter in the  `_get_unavailable_qty` to ignore stock moves from the current rental order and restores the `_get_unavailable_qty` logic to match its cleaner pre-fixed behavior which used to be independent of the rental transfer setting.

opw-4713071

Forward-Port-Of: odoo/enterprise#83689

## Version:
17.0+

## Issue:
Stripe payments with an unregistered card on backdated subscriptions lead to Stripe API refusal.

## Steps to reproduce:
Ensure Stripe is well configured in `Test Mode` with `Credentials`; Create a new Sale Order with `Monthly Cleaning` as `Quotation Template` for any customer:
- Under `Other Info` tab, change the `Subscription` `Start Date` for a date at least 2 days before current date;
- Confirm and create regular invoice:
  - Set `Invoice Date` to the same date as the subscription;
  - Confirm and go to the invoice's preview and start payment process:
    - Use a new card for payment;
    - Check `Save my payment details` checkbox and pay.

## Cause:
The Stripe mandate needs to be filled with a start date at least equal to yesterday (https://docs.stripe.com/api/payment_intents/create#create_payment_intent-payment_method_options-card-mandate_options-start_date). Subscription app sets the start date to the SO's `start_date` via https://github.com/odoo/enterprise/blob/5642ad28919081a44bb47c0d936aa51980178d09/sale_subscription/models/payment_transaction.py#L51-L52. The values are retrieved by `_stripe_prepare_mandate_options()` via https://github.com/odoo/odoo/blob/d231565ec9054556d025b093195a934f28d067c3/addons/payment_stripe/models/payment_transaction.py#L206 and sent to Stipe under a new structure given by https://github.com/odoo/odoo/blob/d231565ec9054556d025b093195a934f28d067c3/addons/payment_stripe/models/payment_transaction.py#L209-L220

## Fix:
Initial suggestion made in the `payment_stripe` module (https://github.com/odoo/odoo/pull/207451), but later moved to the origin of the issue. As of 2025-05-12, Stripe seems to have fixed the issue, but this patch is still applied as a safety measure.

opw-4654142

Forward-Port-Of: odoo/enterprise#85314

When user quickly presses the ``Enter`` key multiple times to record a timesheet,
A traceback will appear.

Steps to reproduce the error:
- Go to Timesheets > My Timesheets
- Now, Quickly press the ``Enter`` key multiple times to record a timesheet

Traceback:
```
ValueError: Expected singleton: timer.timer(1, 2)
  File "home/odoo/src/enterprise/18.0/timesheet_grid/models/analytic.py", line 433, in action_start_new_timesheet_timer
    timesheet.action_timer_start()
  File "home/odoo/src/enterprise/18.0/timesheet_grid/models/analytic.py", line 460, in action_timer_start
    super().action_timer_start()
  File "home/odoo/src/enterprise/18.0/timer/models/timer_mixin.py", line 86, in action_timer_start
    self._stop_timer_in_progress()
  File "home/odoo/src/enterprise/18.0/timer/models/timer_mixin.py", line 140, in _stop_timer_in_progress
    model = self.env[timer.res_model].browse(timer.res_id)
  File "odoo/fields.py", line 1228, in __get__
    record.ensure_one()
  File "odoo/models.py", line 6196, in ensure_one
    raise ValueError("Expected singleton: %s" % self)
```

https://github.com/odoo/enterprise/blob/58348c5f9276e5cb4397f0f73d23b41f5a454868/timer/models/timer_mixin.py#L128-L131 When a user quickly presses the ``Enter`` key,
``timer`` will have multiple records,
So, It will lead to the above traceback.

sentry-6557099219

Forward-Port-Of: odoo/enterprise#73984