**Steps to reproduce:**
1. Install *Inventory* and *Barcode* modules.
2. Disable *Allow Extra Products*:
   - *Configuration* → *Operation Types* → *Internal Transfer*(unarchive if needed) → *Barcode App* tab → uncheck *Allow Extra Products*.
3. In *Settings*, enable *Packages* and *Storage Locations*.
4. Create two storable products, e.g.:
   - Product A → put 10 units in Package PKG-A.
   - Product B → put 15 units in Package PKG-B.
5. Create an *Internal Transfer*:
   - Add Product A manually.
   - From the column dropdown, enable *View Buttons*.  click on `view` on line and create a stock move.
6. Open the *Barcode* app → *Operations* → *Internal Transfer* → select the transfer created.
7. From the gear icon, in *Enter Barcode*, input PKG-B (the package name of Product B) and click *Apply*.

**Observed behavior:**
- The products inside the scanned package are added to the transfer, even though *Allow Extra Products* is disabled.
- Regular (non-packaged) products are correctly blocked.

**Root cause:**
- The check for extra products was only applied when scanning individual products.
- When scanning a package, its contents bypassed the restriction and created new lines for each product.

**Solution:**
- Apply the *Allow Extra Products* restriction also when processing package contents in the barcode picking model.
- Skip the creation of lines for disallowed products and notify the user with a warning message listing the skipped products.

opw-4863621

### Issue:

To reproduce the bug:
1. Activate `Packages` settings in Inventory:
2. Activate `Move entire packages` on picking type `delivery orders`
3. Create new product `Test move package`
4. Update quantity in `WH/Stock` with a newly created package and a qty (eg 5)
5. Go to the delivery orders and create a new picking with the created product and a quantity of 5
6. Click on `Mark as Todo`, the picking is set as ready and a package level is created automatically to move the quantity we did put in stock in the package.
7. Mark the checkbox `Done` on the package level (this will mark the move line and the move as picked)
8. Unmark the checkbox `Done` on the package level.

The package level is deleted, as well as the stock move line,
but the stock move still has the checkbox picked that is
marked.
The picking is then in waiting state and we cannot check
availability again.
Currently to be able to check the availability, the picked
check should be undone manually.

### Cause of issue

Currently, in `_compute_picked` in `stock_move`, we don't
update value of move.picked if there is `no move_line_ids`
present which is wrong.

### Fix:

In the fix, picked is set to False when there no
`move_line_ids`

### Issue 2

This fix cause another issue, in which the move loses its `picked` status after manually setting the done quantity when no stock was initially available,

### Cause of issue 2

To be more specific this fix on `_compute_picked`
```diff
- elif move.move_line_ids:
        move.picked = False
+ else:
        move.picked = False
```
has the following side effect:
- On a confirmed picking, pick a move with a quantity of 0 then change the quantity to 10 the move is unpicked -> undesirable.

After you picked the move, when you set the quantity, you will set `move_line_ids` on your move to match the quantity increase here:
https://github.com/odoo/odoo/blob/57c0ce5f0af9b46c037759d85205bc3e88890af7/addons/stock/models/stock_move.py#L2157-L2165
However,`self._set_quantity_done_prepare_vals(qty)` does not return a `stock.move.line` record set but a `Command.create` whose values do not contain any info on the picked value of the move *line*:
https://github.com/odoo/odoo/blob/57c0ce5f0af9b46c037759d85205bc3e88890af7/addons/stock/models/stock_move.py#L1497-L1507
The fact that the `move_line_ids` is set on the move to this command.create, flags the `picked` field of the stock move to dirty and adds it to the field to recompute because of the dependency `move_line_ids.state`:
https://github.com/odoo/odoo/blob/57c0ce5f0af9b46c037759d85205bc3e88890af7/addons/stock/models/stock_move.py#L208-L209
https://github.com/odoo/odoo/blob/57c0ce5f0af9b46c037759d85205bc3e88890af7/odoo/api.py#L795-L800
THEN, the creation of the move.line happends and since the value of the picked was not set in the command.create, we populate it based on the picked value of the move:
https://github.com/odoo/odoo/blob/57c0ce5f0af9b46c037759d85205bc3e88890af7/addons/stock/models/stock_move_line.py#L347-L348
However, at this point since the picked value of the move has been flagged as dirty it is recomputed using the `compute_method` modified in our fix.
And since the move does not have any move line at this stage, it is computed to be picked = False resetting the picked value.

### Fix of Issue 2:
We should set the picked values in the vals here:
https://github.com/odoo/odoo/blob/57c0ce5f0af9b46c037759d85205bc3e88890af7/addons/stock/models/stock_move.py#L1497-L1507

opw-4964561


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

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

Forward-Port-Of: odoo/odoo#227387

**Steps to reproduce:**
- Install l10n_in and l10n_in_hr_holidays module
- Time off > configuration > Public holidays
- Create a public holiday for Independence Day (15/08/2025)
- Go to Time off > configuration > 'Time off Types',
- Create a Time off type with
   - 'Sandwich leave' ticked and `Take Time Off in` to half a day
- Go to Time off > Management > Time off
- Case 1: Create a paid time off leave for the employee from 13/08 to 17//08/2025 
- Case 2: Create a paid time off with any date and mark it as a half-day

**Observation:**
- Case 1: You will see Duration 3 days with the sandwich leave policy.
- Case 2: Half-day leave shows 1 day instead of 0.5

**Root Cause:**
- Case 1: For the sandwich leave rule, here we checked only one day after and before, leave start and leave end, respectively. It will cause an issue if an employee applies leave that starts or ends with 3 non-working days.
https://github.com/odoo/odoo/blob/5d2f1510c08d5570fc2c6c8de0cb4042bacf12d6/addons/l10n_in_hr_holidays/models/hr_leave.py#L39-L46
- Case 2: We forcefully added a 1-day leave, without checking if the leave is half day or not.
https://github.com/odoo/odoo/blob/5d2f1510c08d5570fc2c6c8de0cb4042bacf12d6/addons/l10n_in_hr_holidays/models/hr_leave.py#L19

**Solution:**
- Case 1: Extend the sandwich leave logic to check every day before and after until a working day is found.
- Case 2: Fixed duration calculation to add 0.5 for half-day leaves.

opw-5025766

---
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

Forward-Port-Of: odoo/odoo#225845

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/67a1b4af88 [REL] 18.0.46 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/0aa0e39c13 [FIX] format: wrong internal format conversion [Task: 5126306](https://www.odoo.com/odoo/2328/tasks/5126306)
https://github.com/odoo/o-spreadsheet/commit/3b48d98c00 [FIX] Evaluation: remove spread relations [Task: 5105030](https://www.odoo.com/odoo/2328/tasks/5105030)
https://github.com/odoo/o-spreadsheet/commit/141465db49 [FIX] headers: can add lots of headers [Task: 5092626](https://www.odoo.com/odoo/2328/tasks/5092626)
https://github.com/odoo/o-spreadsheet/commit/d958b25af8 [FIX] spreadsheet: prevent sheet name edit from losing focus [Task: 5109129](https://www.odoo.com/odoo/2328/tasks/5109129)

Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya <rmbh@odoo.com>
Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>