Since [1] when reloading the browser the breadcrumb is restored based on the URL.

This was implemented in a very naive way. For each action found in the URL, a multiview was added to the breadcrumb. Similarly, for each pain action/ID found in the URL, a form view was added to the breadcrumb. Note that the active_id (found before the action in the URL), is taken into account in the context of the action.

For example, if the URL is : `/odoo/project/5/tasks`:
 - for the `project` action, the list of projects will be added to the breadcrumb;
 - for the `project/5` action/ID pair, the form view of the project 5 will be added;
- for the `5/tasks` action (with active_id 5), the list of tasks for the project 5 will be added.

However, this naive implementation does not consider that the user can navigate directly from the list of projects to the list of tasks for a project without passing through the project form view.

This commit saves the current state in the session storage, to be used to restore the breadcrumb when the page is reloaded.

Note that similar behaviour was implemented to improve action restoration [2].

[1] https://github.com/odoo/odoo/commit/c63d14a0485a553b74a8457aee158384e9ae6d3f
[2] https://github.com/odoo/odoo/commit/e8afebdcbf5d725091983fbe3b425fec4aa3a071

task-id 5011505

Version:

- saas-18.4

Before:

- If a subscription was paused and a manual invoice was created, resuming the
   subscription would set the next invoice date incorrectly.
- It would often pick a date that had already been invoiced manually, skipping
   over the pause period.
- This happened because the user_pause_start is not reset after posting the
   manual invoice.

After:

- Now, when a manual invoice is posted during a pause, the pause state is
   cleared right away.
- This makes sure the next_invoice_date is calculated properly when the
   subscription is resumed, without missing the pause period.

Impact:

- Fixes issues where subscriptions skipped billing periods after a manual invoice
   during a pause.
- Keeps the billing period accurate when pausing and resuming subscriptions.

Steps to reproduce:

- Create and confirm a subscription.
- Pause the subscription.
- Post a manual invoice.
- Resume the subscription.


task-4946268

Forward-Port-Of: odoo/enterprise#90395

## [FIX] sale_renting_planning: make sure shift generated by RO is published

## [FIX] sale_renting_planning: generate shifts when confirming rental order based on uom

Before this commit, when the user creates room product to generate
shifts when a rental order is confirmed with that product, we expect to
generate one shift per quantity ordered if the UoM is Unit instead of
Hours/Days.

This commit improves the shifts generation to take into account the UoM
set on the SOL linked to rental order confirmed. That is, if the UoM set
is Unit then one slot per unit ordered of the product will be generated.
Otherwise, one shift will be generated for the SOL as it is currently
the case.

## [FIX] sale_renting_planning: make sure to not overload the rental service

Before this commit, when the user creates a new shift and clicks on `Add
to Last Order` the shift will be added to the SOL contained one of
products linked to the role set on the shift. The problem is we don't
check if there is still something to plan for that SOL.

This commit makes sure the SOL to set to the shift has something to plan
to be sure it is not overloaded.

task-4916537

Forward-Port-Of: odoo/enterprise#91327

### Steps to reproduce:
	- Set timesheets inovicing policy to 'Validated Timesheets Only'
	- From the portal go to any task that has some validated timesheet and some other not
	- Notice that the lines shown is the validated ones only but the Hours spent includes the non-validated ones too

### Current behavior before PR:
The total hours spent for timesheets in portal view when setting the invoicing policy to 'Validate Timesheets Only' is calculated wrongly as it takes the non validated ones into account.

This is happening as when passing the values to the view we pass 'task_sudo' variable which will have the SUPERUSER as the env.user

https://github.com/odoo/odoo/blob/saas-17.2/addons/project/controllers/portal.py#L569

so it won't pass the condition if the user is portal or not https://github.com/odoo/enterprise/blob/saas-17.2/sale_timesheet_enterprise/models/project_task.py#L33:L35 and it will calculate all the timesheet without taking validation into condisderation.

### Desired behavior after PR is merged:
As we are using those computed fields only in portal views so we don't have to check if the user is portal user as even if an internal user is showing the same view for testing he should be able to see the same data as the portal user.

opw-4193842

Forward-Port-Of: odoo/enterprise#70557