Currently, an error will occur when user multi edits name of projects.

Steps to replicate:
- Install `project` and open projects.
- From the list view select multiple projects and edit their name.

Error:
```
File '/home/odoo/src/odoo/saas-19.3/addons/project/models/project_project.py', line 754, in write
    analytic_account_to_update.write({'name': self.name})
File '/home/odoo/src/odoo/saas-19.3/odoo/orm/fields.py', line 1728, in __get__
    record.ensure_one()
File '/home/odoo/src/odoo/saas-19.3/odoo/orm/models.py', line 5341, in ensure_one
    raise ValueError('Expected singleton: %s' % self)
ValueError: Expected singleton: project.project(8, 9, 10)
```

Cause:
- As multiple records were changed at the moment, `self` had multiple recordsets and trying to access `self.name` [1] causes this error.

Solution:
- Avoided accessing `self.name` on a multi-recordset during multi-edit.
- Updated analytic account names using the name recieved in the vals.

[1]: https://github.com/odoo/odoo/blob/a69ec43f490735f639292d116b0207182c5b2581/addons/project/models/project_project.py#L608

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

Forward-Port-Of: odoo/odoo#267620

Steps:
- Install an Odoo 17.0 database with the Indian Payroll module and demo data.
- Upgrade the database to 18.0.

Issue:
- The Indian payroll demo data creates leave allocations and approves them through an XML function call.
- During a fresh installation, demo files are loaded in 'init' mode, so the approval function is executed and the allocations move from 'confirm' to 'validate'.
- However, during a 17.0 >>> 18.0 upgrade, demo files are loaded in 'update' mode. Odoo automatically loads demo files with 'noupdate=True' from the load_demo() >> load_data() function:
- This value is passed to the XML importer and becomes the default noupdate state for the file. Since the demo XML file does not explicitly override this value, the function tag uses 'noupdate=True'.
- When the XML parser reaches the approval function, _tag_function() skips its execution because of noupdate = 'True' and mode = 'update' condition.
- As a result, the approval function is not executed during the upgrade and the leave allocations remain in 'confirm' state. Subsequent demo payroll data expects validated allocations and fails during loading.

Fix:
- Explicitly set 'noupdate=0' on the demo XML file. This overrides the default 'noupdate=True' value applied to demo files, making the parser evaluate the section with 'noupdate=False'.
- As a result, '_tag_function()' executes the approval method during upgrades, the demo leave allocations are validated in both fresh/new db installations and 17.0 >>> 18.0 upgrade scenarios.

runbot error-https://runbot.odoo.com/odoo/error/230430 

task-6268381

Forward-Port-Of: odoo/enterprise#119217

Version:
- 19.0

Steps to reproduce:
- Install Attendances and Time Off
- Create an internal user.
- Give the user: Attendances Officer access & No Time Off Officer/Manager rights
- Create an employee linked to the user.
- Configure the employee with a Flexible Working Schedule.
- Create and approve a Time Off request for the employee.
- Open: Attendances -> Gantt View
- Navigate to the month containing the employee's approved leave.

Issue:
- An access error is raised when opening a month that contains the employee's
  approved leave.

Cause:
- In `_handle_flexible_leave_interval`, the code accesses `leave.holiday_id`
  to read fields such as `request_unit_half`, `request_unit_hours`, and
  `request_hour_from/to` on the `hr.leave` model.
- When the current user has Attendances Officer rights but no Time Off
  access(rare cases), the ORM access check on `hr.leave` raises an AccessError,
  even though this read is purely for internal calendar computation and
  does not expose leave data to the user interface.
 
Fix:
- Added sudo() on holiday_id to access the employee's leave details
  and compute the work interval as expected.

Task-6264510

### Issue
On Runbot, trial, and client databases, the automatic extraction of the description does not work when a user changes the database language

When an expense is first generated up to 19.0, it requires a name and is temporarily given a localized placeholder like "Dépense sans titre..." in French

When the OCR results arrive, the system is supposed to detect this generic fallback string and overwrite it with the real extracted description

However, because of a language mismatch, the system fails to recognize its own placeholder. It incorrectly assumes the user manually entered that text and, to prevent losing user data, refuses to replace it

Before the fix, the title remains stuck on the placeholder
In very rare cases, the translation applies correctly, but it fails most of the time

### Cause
The OCR successfully finds the correct description, but in `_fill_document_with_results`, the expense name is not replaced

This seems to happen because `self` in `self._get_untitled_expense_name("")` carries a residual context that could override the correct language to use during the automated extraction process

Even though the user record and the detected language are correctly set to the alternative language, `default_receipt_name` appears to be generated in English ("Untitled Expense")

This would cause the subsequent string comparison with the actual translated name stored in the database to fail, blocking the update

### Fix
I made some tests in some generated RunBot and the user is correct and also the associated lang

I supposed self was containing lang details overriding the correct language to use

`self.env['hr.expense'].with_context(lang=user_id.lang)` seems to be working

### Steps to reproduce
The issue cannot be reproduced locally, follow these steps on a Runbot instance:
- Retrieve IAP OCR credentials from a trial database
- Enable Developer Mode in Settings
- Go to Settings -> Technical -> IAP -> IAP Accounts
- Add the credentials for the Document Digitization service
- Go to the Expenses app
- Change the user's language to French
- Import the expense image from the ticket
- Open the newly created Expense and click Refresh

Before the fix, the title should stay `Dépense sans titre...` If it's not the case, try a second import, it works times to times

opw-6103935

Forward-Port-Of: odoo/enterprise#118661