Delivery labels can now be opened directly from a delivery order in a new browser tab. This makes it faster for warehouse and shipping teams to find and print carrier labels, while related pop-up windows close cleanly after the label opens.

Task: https://www.odoo.com/web?#id=21062&view_type=form&model=project.task&action=327
Pad: https://pad.odoo.com/p/r.MEzWuDJ0aazvLCVk

[ADD]Delivery: Add controller which read pdf from attachment and make response.
[ADD]Delivery: Add print_label_id many2one field in picking. 
[ADD]Delivery: Add print label stat button which open pdf from Delivery attachment in new tab.
[IMP]Delivery: Use ir.actions.act_url to redirect in new tab.
[IMP]web: close wizard when action kind of url is returned.

This adds an embedded code editor experience for selected text fields in the web interface, making it easier to edit structured or code-like content. The editor loads only when needed, helping provide richer editing tools without unnecessarily slowing regular pages.

use with `widget="ace"` on text fields

The eCommerce checkout delivery setup now better shows which delivery destinations are available depending on whether a pricelist is used. This helps businesses present more accurate shipping options to customers and reduce confusion during checkout.

Task: https://www.odoo.com/web#id=11947&view_type=form&model=project.task&action=327
Pad: https://pad.odoo.com/p/r.6CuktgblCC4DQVK7

This update improves several configuration screens so administrators can find and manage reports, actions, translations, models, and automated rules more easily. It adds more focused search options and tidies report-related views, reducing time spent navigating technical settings.

https://www.odoo.com/web/#id=22267&view_type=form&model=project.task&action=327&menu_id=4720

Accounting users can define payment terms based on combinations such as a number of days followed by the end of that month, or month-end plus days to a chosen day in the next month. This makes invoice due dates easier to match to real customer and supplier agreements without manual workarounds.

Description of the issue/feature this PR addresses:

TASK: https://www.odoo.com/web#id=24239&view_type=form&model=project.task&action=327&menu_id=4720
PAD: https://pad.odoo.com/p/r.9e5aba2e0e5bf1329fe090065d936f9b

Current behavior before PR:
Payment term scenario like Current date +  45days + Last day of arrive month  is not possible currently 

Desired behavior after PR is merged:
Terms like current date + days + last of month and month end + days + desire day of next month possible with this PR
## 

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

FedEx shipping labels are now named more clearly when a delivery has multiple labels, making it easier for users to identify and manage the right document. The related workflow also closes pop-up windows correctly after opening label links, reducing confusion and extra manual steps.

[IMP]Delivery_fedex: Change labelfedex attachment when there is multiple label for fedex.
changed it to "LabelFedex-1-tracknumber", LabelFedex-2-tracknumber",...

Task: https://www.odoo.com/web#id=21062&view_type=form&model=project.task&menu_id=3942&action=327Pad: https://pad.odoo.com/p/r.MEzWuDJ0aazvLCVk

Report generation now accepts different record formats consistently, reducing errors when printing from older or migrated workflows. The first printed report also displays correctly by restoring required report context during PDF generation.

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

… as 'docids'

1/ If no docids are passed in get_action (empty list) do not put in context

2/ The method should accept ids or browse records as docids for retrocompatibility.
- The api.v7 method took ids as docids
- The api.v8 method took a browse records 'records' to call the api.v7 method with
  'records.ids' as docids
  In python, we cannot write 2 functions with the same name that takes differents types
  for the same argument. The function 'guess' in api.py will lead to a crash if we expect
  a browse record and we send a list
  The only way to allow the method to receive different types for the same argument is
  to decorate it with '@api.noguess' to prevent any effect from guess method.
  That way, we check directly if 'docids' is an id, ids or a browserecord and we always set
  a list instead.