Track 3 Tier 2: MW-by-domain config, Application Links API, Mongo 7 upgrade, smart routes, L1-port filter

.wordlist.txt

@@ -1648,3 +1648,8 @@ undeploys
 paginated
 pagination
 UndeployApps
+FCV
+setFeatureCompatibilityVersion
+featureCompatibilityVersion
+Telnet
+sharded

docs/admin/cloudshell-manage-dashboard/maintenance-window.md

@@ -69,19 +69,38 @@ The maintenance window's areas are arranged as follows:
 
 *New in CloudShell 2026.1*
 
-In addition to the system-wide maintenance window described above, administrators can define maintenance windows scoped to individual domains. During a domain-scoped maintenance window, sandbox creation and modifications are restricted in that domain, while other domains continue operating normally.
+In addition to the system-wide maintenance window described above, administrators can define maintenance windows scoped to individual domains. During a domain-scoped maintenance window, the same restrictions described in [About the maintenance window](#about-the-maintenance-window) (login, sandbox reservation, and automation) apply only to the selected domain. Other domains keep operating normally.
 
-This is useful for planned infrastructure maintenance, upgrades, or other activities that require temporarily restricting access to specific lab resources without affecting other teams.
+This is useful for planned infrastructure maintenance, upgrades, or other activities that require temporarily restricting access in a specific domain without affecting other teams.
+
+A domain-scoped maintenance window uses exactly the same schedule, notification duration, and messages (**Message on Login**, **Notification Message**, **Error on Reserve**, and **Warning on Reserve**) as a system-wide window. The only difference is the domain the window applies to:
+
+- A window associated with the **Global** domain is system-wide and applies to all domains (this is the default for windows created from the **Global** domain, as described in [Setting a maintenance window](#setting-a-maintenance-window)).
+- A window associated with a specific domain applies only to that domain.
+
+Each domain can have at most one active or planned maintenance window at a time, independently of other domains.
 
 ### Configuring a Domain Maintenance Window
 
-To set a maintenance window for a specific domain, use the API:
+A domain maintenance window is configured the same way as a system-wide one — by adding a maintenance window and associating it with the target domain, rather than with the **Global** domain.
 
-- **UpdateDomainSetting** — Set maintenance window parameters for a specific domain
-- **GetDomainSettings** — Retrieve current domain settings including maintenance window configuration
+**To set a maintenance window for a specific domain:**
+
+1. As system administrator, open the **Manage** dashboard.
+2. In the page navigation bar, click **Maintenance Window**.
+3. Click the **Add New Maintenance Window** button.
+4. Associate the window with the domain you want to place under maintenance (instead of the **Global** domain).
+5. Enter the schedule, notification duration, and messages, as described in [Navigating the maintenance window](#navigating-the-maintenance-window). These fields behave identically to a system-wide window.
+6. Click **Save**.
+
+The window follows the same lifecycle as a system-wide window (**NEW** → **PLANNED** → **ACTIVE**), and can be extended, stopped, or deleted the same way. The restrictions take effect only for users of the associated domain.
+
+:::note
+The values you provide are the same as for a system-wide window: a schedule (start time and duration), a notification duration (how long before the start time to display the **Notification Message**), and the four maintenance messages. The maintenance window is not configured through a per-domain "domain setting" value — associating the window with a domain is what scopes it. The exact placement of the domain selection in the UI may vary by version.
+:::
 
 :::note
-The system-wide maintenance window (configured from the **Manage** dashboard) takes precedence over domain-level maintenance windows. If both are active, the system-wide restrictions apply.
+The system-wide maintenance window (a window associated with the **Global** domain) takes precedence over domain-level maintenance windows. If both a Global and a domain-scoped window are active, the system-wide (Global) restrictions apply.
 :::
 
 ## Related Topics

docs/admin/setting-up-cloudshell/assembly-lab/index.md

@@ -29,6 +29,36 @@ When creating routes between concrete devices in the sandbox, the system priorit
 
 If no valid route can be established through existing L1 infrastructure, a provisional direct connection (device-to-device) is created. This placeholder route can later be refined by selecting appropriate connections through Layer 1 switches or patch panels.
 
+#### How the system chooses the route
+
+When you connect two concrete devices, the system evaluates the physical topology and resolves the connection in this order of preference:
+
+1. **A path through existing Layer 1 infrastructure.** If the two devices are wired into the same L1 switch or reachable across the L1 fabric through patch panels and Layer 1 switches, the system builds the route along that physical path. This reuses the cabling that is already in place rather than requiring a dedicated direct link.
+2. **A provisional direct (device-to-device) connection.** If no valid physical path can be found through the L1 infrastructure, the system still creates the connection as a provisional direct link between the two devices. This lets you proceed with the sandbox even when the L1 route is not yet available, consistent with the Assembly Lab principle that a sandbox is always created even if not all requirements are met.
+
+A provisional direct connection is a placeholder. You can refine it later (see below) once the appropriate L1 path exists or once you decide which L1 segments the route should traverse.
+
+#### Creating a route between two devices
+
+Work in the sandbox (or in the blueprint's diagram editor) that contains both concrete devices:
+
+1. Open the sandbox or blueprint that contains the two devices you want to connect.
+2. In the diagram, select the first device, then draw a connection to the second device to request a route between them.
+3. Confirm the connection. The system automatically evaluates the L1 topology and either establishes the route through the existing Layer 1 infrastructure or creates a provisional direct connection if no such path is available.
+4. Inspect the resulting connection in the diagram to see whether it was resolved through L1 infrastructure or created as a provisional direct link.
+
+#### Refining a provisional direct connection
+
+If the system created a provisional direct connection because no L1 path was available, you can refine it later:
+
+1. Locate the provisional connection between the two devices in the diagram.
+2. Once the required cabling exists — for example, after both devices are connected to the same Layer 1 switch or reachable through a patch panel — re-evaluate the connection so the system can resolve it through the L1 infrastructure.
+3. Verify that the refined route now traverses the intended Layer 1 switches or patch panels.
+
+:::note
+When a route already exists between the resources, the route itself is not solved (Layer 1 ports are not reserved). This behavior is described under [Route Handling](#route-handling) above; the system still prefers resources that are connected to Layer 1 switches when selecting devices.
+:::
+
 ### L1 Port Auto-Add on Solve
 
 When solving an abstract requirement that is part of a route, if the solution resource is connected to a Layer 1 port, that port is automatically added to the route and reservation. This eliminates the need to manually manage L1 port assignments when resolving abstract requirements within routes.

docs/api-guide/shell-dev-blueprint-design-api/manage-resource-application-links.md

@@ -0,0 +1,85 @@
+---
+sidebar_position: 3
+---
+
+# Managing Resource Application Links
+
+Application links are the remote-access shortcuts (such as **SSH**, **Telnet**, and **RDP**) that CloudShell displays for a resource that allows remote connections. Starting in CloudShell 2026.1, the TestShell API lets administrators control which of these links are available, either on an individual resource or as a default for an entire resource family. This is useful when you want to hide connection methods that are not relevant, not permitted, or not supported for certain equipment.
+
+The feature is exposed through four TestShell API methods:
+
+| Method | Purpose |
+| --- | --- |
+| `SetResourceApplicationLinks` | Set which application links are disabled for a specific resource. |
+| `GetResourceApplicationLinks` | Get the current application links configuration for a resource. |
+| `SetFamilyDefaultApplicationLinks` | Set the default disabled application links for an entire resource family. |
+| `GetFamilyDefaultApplicationLinks` | Get the family-level default configuration. |
+
+These methods are TestShell API methods, available across the TestShell API library, C#, TCL, and XML RPC implementations described in [TestShell API](./testshell-api.md). They are administrator operations and require an administrator session.
+
+## How disabled links are identified
+
+An application link is identified by its **application name** — the name of the remote-access application, for example `SSH`, `Telnet`, or `RDP`. Both `Set` methods take an array of these application names. The array is a list of the links you want to **disable**; any link whose application name is not in the array remains enabled.
+
+The set of link names that actually exist for a resource comes from the application links configured in your CloudShell system, and depends on the resource's attributes (for example, a link is only shown if the attributes it needs, such as address and credentials, are present) and on the resource's family allowing remote connections. Rather than assume a fixed list, retrieve the current configuration first (see [Get the links currently configured on a resource](#get-the-links-currently-configured-on-a-resource)) to discover the exact application names available in your environment before disabling them.
+
+:::note
+Setting the disabled links is a **replace-all** operation. The array you pass completely replaces the previous list of disabled links — it is not merged with it. To change one link, send the full list of links that should be disabled after the change.
+:::
+
+## Resource-level configuration
+
+`SetResourceApplicationLinks(resourceFullPath, disableApplicationLinks)` controls the disabled links for a single resource, where:
+
+- `resourceFullPath` — the full path of the resource (as with other TestShell API resource methods, you can also pass just the resource name without its folders).
+- `disableApplicationLinks` — an array of application names to disable.
+
+A resource has three possible states, determined by the value you pass:
+
+| Value passed | Meaning |
+| --- | --- |
+| An array of application names | Those links are disabled on this resource; all other links are enabled. This overrides the family default. |
+| An empty array | All links are enabled on this resource, overriding the family default. |
+| No value (null) | The resource clears its own setting and inherits the family default. |
+
+## Family-level default configuration
+
+`SetFamilyDefaultApplicationLinks(familyName, disableApplicationLinks)` sets a default for the whole family, where:
+
+- `familyName` — the name of the resource family.
+- `disableApplicationLinks` — an array of application names to disable by default.
+
+The family default applies to any resource in the family that has not been individually configured (that is, a resource still inheriting from its family). Passing an empty array (or no value) clears the family default, so that by default no links are disabled for the family.
+
+A resource-level setting always takes precedence over the family default. Once you call `SetResourceApplicationLinks` on a resource with an array (including an empty array), that resource stops following the family default until you explicitly return it to the inheriting state.
+
+## Reading the current configuration
+
+`GetResourceApplicationLinks(resourceFullPath)` and `GetFamilyDefaultApplicationLinks(familyName)` both return a response containing:
+
+- `DisabledApplicationLinks` — the list of application names that are currently disabled. For a resource that is inheriting, this reflects the family default that is in effect.
+- `InheritingFromFamily` — for `GetResourceApplicationLinks`, indicates whether the resource is currently inheriting the family default (`true`) or using its own explicit setting (`false`).
+
+## Common tasks
+
+The parameter names and values below are the same regardless of which TestShell API implementation (library, C#, TCL, or XML RPC) you use. When calling through XML RPC, wrap the `disableApplicationLinks` array as a string vector according to the XML RPC conventions of your CloudShell version.
+
+### Get the links currently configured on a resource
+
+Call `GetResourceApplicationLinks` with the resource's `resourceFullPath` (for example, `MyRouter`). Do this first, both to see which links are disabled and to discover the exact application names available for the resource. In the response, `DisabledApplicationLinks` lists the currently disabled application names, and `InheritingFromFamily` tells you whether the resource is following its family default.
+
+### Disable a single link on a resource
+
+Call `SetResourceApplicationLinks` and pass the full list of links that should be disabled. To disable only the SSH link, pass `resourceFullPath` = `MyRouter` and `disableApplicationLinks` = `["SSH"]`. Because this is a replace-all operation, the array must contain every link you want disabled, not just the one you are changing.
+
+### Enable all links on a resource (override the family default)
+
+Call `SetResourceApplicationLinks` with `resourceFullPath` = `MyRouter` and an empty `disableApplicationLinks` array. This enables every link on the resource and stops it from inheriting the family default.
+
+### Set a family-wide default
+
+Call `SetFamilyDefaultApplicationLinks` with `familyName` = `Router` and `disableApplicationLinks` = `["Telnet"]` to disable the Telnet link by default for every resource in the `Router` family that has not been individually configured. New resources created in the `Router` family, and existing resources still inheriting from the family, will have their Telnet link disabled. Any resource that already has its own resource-level setting is unaffected.
+
+:::note
+These methods require an administrator session. If the resource or family cannot be found, the call returns an "entity not found" error.
+:::