Currently, leads are not automatically assigned via rule-based assignment 
when duplicating an existing lead, even if the duplicated lead matches 
the assignment criteria.

**Pre-requisites:**
1) Set up rule-based lead assignment in the CRM settings. 
2) Configure the sales team's assignment domain:
   `[("user_id", "=", False)]`
3) Configure the sales team members' domain:
   `[("probability", ">=", 10)]`

**Steps to Reproduce:**

1) Create a lead that matches the above assignment rules. 
2) Remove the salesperson (user_id) and sales team from the lead. 
3) Duplicate the lead.
4) Update the probability to a valid value (e.g., ≥ 10). 
5) Manually trigger the `Rule-Based Assignment`.

**Issue:**
The original lead gets assigned, but the duplicated one does not.

**Cause:**
When duplicating, the system sets date_open to the current date by default, 
even if the duplicated and original leads have no assigned users.

https://github.com/odoo/odoo/blob/3e7d85cf25386615dea559d954cebb1424b62f35/addons/crm/models/crm_lead.py#L929-L931

However, `rule-based assignment` only considers leads where `date_open` is False https://github.com/odoo/odoo/blob/3e7d85cf25386615dea559d954cebb1424b62f35/addons/crm/models/crm_team_member.py#L136-L141

**Solution:**
Set `date_open` to False during duplication if the original lead has no `user_id`. 
This ensures the new lead remains eligible for assignment.

opw-5003529

The field is `required=True`, which automatically sets it `NOT NULL` (if possible). The constraint does not do anything useful.

Furthermore, pg18 promoted `NOT NULL` to "real" named constraints[1], and the constraint was created following the pattern pg uses, so trying to migrate a database to pg18 (either upgrading a cluster from 17 to 18 or restoring a db on a pg18) the restoration fails with

    duplicate key value violates unique constraint "pg_constraint_conrelid_contypid_conname_index"

The easiest fix is to delete the constraint in the upstream DB if possible (I didn't find a way to filter out constraints from pg_dump or pg_restore, though it should be possible to filter it out from a "plain" dump by hand).

AFAIK Odoo does not generally drop constraints so I don't think this will fix existing databases, but it at least makes future databases compatible with pg18.

[1]: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=a379061a22a8fdf421e1a457cc6af8503def6252

Forward-Port-Of: odoo/odoo#229274

**step to reproduce:**
- start a database with worker, use `--max-cron-thread=1 --workers=2`
- Add a sample cron, which runs every minute(just so that we can see the status)
- install helpdesk
- uninstall helpdesk

**Observation**
- traceback in console
```
2025-09-25 06:07:26,389 18450 ERROR ? odoo.service.server: Worker WorkerCron (18450) Exception occurred, exiting... 
Traceback (most recent call last):
  File "/home/odoo/odoo/codebase/odoo/17.0/odoo/service/server.py", line 1171, in _runloop
    self.process_work()
  File "/home/odoo/odoo/codebase/odoo/17.0/odoo/service/server.py", line 1270, in process_work
    base.models.ir_cron.ir_cron._process_jobs(db_name)
  File "/home/odoo/odoo/codebase/odoo/17.0/odoo/addons/base/models/ir_cron.py", line 139, in _process_jobs
    registry[cls._name]._process_job(db, cron_cr, job)
  File "/home/odoo/odoo/codebase/odoo/17.0/odoo/addons/base/models/ir_cron.py", line 331, in _process_job
    now = fields.Datetime.context_timestamp(ir_cron, datetime.utcnow())
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
....
....
  File "/home/odoo/odoo/codebase/odoo/17.0/odoo/models.py", line 3873, in fetch
    fetched = self._fetch_query(query, fields_to_fetch)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo/codebase/odoo/17.0/odoo/addons/base/models/res_users.py", line 546, in _fetch_query
    records = super()._fetch_query(query, fields)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo/codebase/odoo/17.0/odoo/models.py", line 3965, in _fetch_query
    self.env.cr.execute(query.select(*sql_terms))
  File "/home/odoo/odoo/codebase/odoo/17.0/odoo/sql_db.py", line 335, in execute
    res = self._obj.execute(query, params)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
psycopg2.errors.UndefinedColumn: column res_users.helpdesk_target_closed does not exist
LINE 1: ...s"."odoobot_state", "res_users"."odoobot_failed", "res_users...
```

Issue:
- traceback occurred, as the system is try to fetch fields related to helpdesk module
which do not exists now after uninstalling it. 
- cron in case of workers, use daemon threads [1]
- the uninstalled happened with main thread and registry is updated.
- the daemon thread is unaware of this change.
- the `_process_jobs` uses the registry, without checking if it needs reload

[1]: https://github.com/odoo/odoo/blob/e82fdfaf621f45515b92c891334595250accbfbd/odoo/service/server.py#L582-L587

FIx:
- when assigning the registry, we check if needs a reload or not.

opw-5062313

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

This PR addresses the following issues:

**Issue 1: Date Misalignment**

**Steps to Reproduce:**
1. Navigate to website → Blog Page → Edit.
2. Change the layout from Grid to List.
3. Toggle the Cards button on.
4. The date and tags will appear slightly misaligned.

**Solution:**
Adding `#{` code in the `t-attf-class` attribute will align the date with the blog post content and tags.

**Expected Behavior:**
The date should align with the blog post content and tags preview.

**Issue 2: Some Tag Filters Getting Removed**

**Steps to Reproduce:**
1. Add a date filter from the sidebar of the blog.
2. Remove this filter by clicking the X button.
3. If multiple tags are present in the filter section, only the first tag remains while the rest are removed when the date filter is added or removed.

**Solution:**
Sending a POST request whenever the date filter is selected or removed. To achieve this, we introduced the `post_link` class to the `<select>` and `<a>` elements. When a date option is chosen, the click event triggers the `_onClickPost` handler 
function, which extracts the URL from the `value` attribute of the `<option>` tag.


**Expected Behavior:**
All previously added tags should remain after adding or removing the date filter.

**Issue 3: All Tag Filters Getting Removed**

**Steps to Reproduce:**
1. Navigate to website → Blog Page → Turn On the Sidebar.
2. Select any tag from the tags section in the sidebar.
3. Ensure no blog is selected.
4. Select a date from the archives in the sidebar.
5. Change the date to '-- All Dates' in the archives dropdown.
6. All tags in the filter are removed along with the date.

**Solution:**
Removing the condition for navigation based on whether a blog is present or not will ensure tags remain in the filter section after selecting the '-- All Dates' option.

**Expected Behavior:**
Tags present in the filter section should remain after selecting the '-- All Dates' option.

task-3937884

- In version 18, the force_create parameter was introduced in the try_loading method. https://github.com/odoo/odoo/pull/198030/commits/8153a957746d7ad11db5df743a948c471d828f15
  Therefore, the upgrade fails when try_loading with the force_create parameter
  is used in version 17.
https://github.com/odoo/odoo/pull/223405/files#diff-25bc11e6653e875717f3a1c96d0773f08c59c68d0290011f217c7e877fb06d0b
 In version 17, this parameter is not available for the try_loading method.
https://github.com/odoo/odoo/blob/17.0/addons/account/models/chart_template.py#L131

```python3
Traceback (most recent call last):
  File "/home/odoo/src/odoo/17.0/odoo/service/server.py", line 1369, in preload_registries
    registry = Registry.new(dbname, update_module=update_module)
  File "<decorator-gen-16>", line 2, in new
  File "/home/odoo/src/odoo/17.0/odoo/tools/func.py", line 87, in locked
    return func(inst, *args, **kwargs)
  File "/home/odoo/src/odoo/17.0/odoo/modules/registry.py", line 110, in new
    odoo.modules.load_modules(registry, force_demo, status, update_module)
  File "/home/odoo/src/odoo/17.0/odoo/modules/loading.py", line 519, in load_modules
    migrations.migrate_module(package, 'end')
  File "/home/odoo/src/odoo/17.0/odoo/modules/migration.py", line 221, in migrate_module
    exec_script(self.cr, installed_version, pyfile, pkg.name, stage, stageformat[stage] % version)
  File "/home/odoo/src/odoo/17.0/odoo/modules/migration.py", line 239, in exec_script
    migrate(cr, installed_version)
  File "/home/odoo/src/odoo/17.0/addons/l10n_ee/migrations/1.3/end-migrate_update_data.py", line 7, in migrate
    env['account.chart.template'].try_loading('ee', company, force_create=False)
TypeError: AccountChartTemplate.try_loading() got an unexpected keyword argument 'force_create'

```

upg-3164417
tbg-2185

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Current Behavior:
When reserving product quants for a picking, quants will be selected from
children locations of the selected location, even if they are from a
company not accessible to the current user.
In Odoo 18 and Odoo 19, this also causes an Access Error to occur when
trying to view the product's On-Hand Quantity while in the picking's
company.

Expected Behavior:
Quants should only be reserved from locations in companies the current
user has enabled.

Steps to reproduce:
1. Enable Locations in Inventory
2. Create a Location with no Company set, then set it as the parent of
   the Stock locations in Companies X and Y
2. Create a new Stored Product and add a Quant for it in Company X
3. Create a Quotation in Company Y including the product and confirm it
4. In the Delivery connected to the Sale Order, set the Source Location
   to the created parent Location, then select Check Availability

Fix:
Modify the gather domain to only include records from active companies.

opw-5096469