adding work order document, plus moved stuff around a bit

docs/admin/cloudshell-identity-management/cloudshell-domains/adding-domains.md

@@ -18,3 +18,10 @@ Designated system administrators have limited permissions for performing domain
 4. Add a short description of the domain. This step is optional but recommended.
 5. Click **OK** to add the new domain.
 6. Next, set up the domain, as explained in [Domains Window](../../../admin/cloudshell-identity-management/cloudshell-domains/domains-window.md).
+
+
+**Minimum Lead Time**
+
+You have the ability to establish a minimum lead time for reserving Sandboxes within a specific domain. This means that when this setting is configured, any sandbox reservations must be made for a date in the future, not for immediate use.
+
+To implement this, you need to adjust the `MinimumLeadTimeMinutes` parameter via a specific API call. Detailed instructions on how to make this API call can be found in [this guide](../../../api-guide/cs-admin-rest-api/edit-domain.md).

docs/admin/cloudshell-identity-management/managing-cloudshell-permissions/capabilities/index.md

@@ -0,0 +1,45 @@
+---
+title: Managing Capability Sets in CloudShell
+sidebar_label: Capability Sets
+---
+
+## Understanding Capability Sets in CloudShell
+
+In Quali's CloudShell environment, user permissions are traditionally governed by roles assigned to user groups, such as system admins, domain admins, regular users, and external users. Each role comes with predefined permissions within specific domains.
+
+### Role-Based Permissions
+
+By default, roles dictate what actions users can perform within CloudShell. These permissions include accessing settings, managing execution servers, handling categories, viewing sandbox data, managing users and permissions, modifying resources and services within blueprints and sandboxes, and more.
+
+### Introducing Capability Sets
+
+However, to provide more granular control over permissions, CloudShell introduces Capability Sets. These sets allow administrators to define specific capabilities that either **ALLOW** or **DENY** actions beyond what roles permit. This flexibility enables organizations to tailor access rights precisely to their operational needs.
+
+### Managing Capability Sets
+
+Capability Sets can be managed through both the CloudShell API and the CloudShell Portal. In the portal, administrators navigate to **MANAGE > Permissions** to create new capability sets. Here, they can associate specific capabilities with these sets, specifying whether each capability is allowed or denied.
+
+### Associating Capability Sets with User Groups
+
+Administrators can then associate these Capability Sets with user groups. If multiple Capability Sets apply to a user group, the system prioritizes the most permissive settings for each capability.
+
+### Example Capabilities
+
+- **VIEW SETTINGS**: Access to the Manage page in CloudShell Portal.
+- **VIEW EXECUTION SERVERS**: Access to Manage/Execution Servers.
+- **VIEW_CATEGORIES**: Access to Manage/Categories.
+- **VIEW_SANDBOX_DATA**: Access to sandbox data in CloudShell Portal.
+- **MANAGE_USERS_PERMISSIONS**: Ability to manage Capability Sets and Roles.
+- **ADD_REMOVE_BLUEPRINT_RESOURCE**: Add or remove resources from blueprints.
+- **ADD_REMOVE_SANDBOX_RESOURCE**: Add or remove resources from sandboxes.
+- **ADD_REMOVE_BLUEPRINT_ABSTRACT_RESOURCE**: Modify abstract resources in blueprints.
+- **ADD_REMOVE_SANDBOX_ABSTRACT_RESOURCE**: Modify abstract resources in sandboxes.
+- **ADD_REMOVE_BLUEPRINT_SERVICE**: Add or remove services from blueprints.
+- **ADD_REMOVE_SANDBOX_SERVICE**: Add or remove services from sandboxes.
+- **UPDATE_WORK_ORDER**: Make changes to work orders.
+- **VIEW_WORK_ORDER**: View work orders within sandboxes.
+- **UNSOLVE_SANDBOX_ABSTRACT**: Modify abstract matches in sandboxes.
+
+## Conclusion
+
+Capability Sets in CloudShell provide a powerful tool for fine-tuning user permissions, ensuring that organizations can manage access rights precisely according to their operational requirements. By allowing specific overrides to role-based permissions, Capability Sets empower administrators to tailor operations to their organization's needs.

docs/admin/setting-up-cloudshell/cloudshell-configuration-options/assembly-lab/_category_.json → docs/admin/setting-up-cloudshell/assembly-lab/_category_.json

@@ -1,4 +1,4 @@
 {
   "label": "Assembly Lab",
-  "position": 20
+  "position": 4.5
 }

docs/admin/setting-up-cloudshell/assembly-lab/a-common-use-case.md

@@ -0,0 +1,35 @@
+---
+sidebar_position: 10
+---
+# A Common Use Case
+
+## Overview
+In a typical use case, Assembly Lab facilitates collaboration between two groups of users: lab managers and customers.
+
+### Lab Managers
+
+- Responsible for managing the lab and overseeing work orders.
+- Ensure that resources are allocated efficiently and that the lab environment meets the specified requirements.
+
+### Customers
+
+- Submit requests using blueprints, which may represent new use cases or environments.
+- Interact with lab managers through the sandbox to negotiate requirements and find solutions.
+
+## Recommendations
+
+#### Sandbox Interaction
+
+The sandbox environment enables lab managers and customers to negotiate over requirements and make adjustments as needed. This can involve shifting devices around or changing abstract requirements to something more feasible.
+
+#### Capability Sets
+
+User groups can be managed through capability sets, ensuring that each group has the appropriate access levels and permissions.
+
+#### Sticky Notes
+
+Sticky notes can be placed in blueprints and sandboxes to clarify requirements and communicate important information.
+
+#### Work Order Comments
+
+Lab managers can leave comments on each record in the work order, allowing customers to track progress and stay informed about the status of their requests.

docs/admin/setting-up-cloudshell/assembly-lab/configure-assembly-lab-domain.md

@@ -0,0 +1,17 @@
+---
+sidebar_position: 2
+---
+# Configure an Assembly Lab Domain
+
+To leverage the capabilities of Assembly Lab, a domain must be configured to the Assembly Lab domain. Once the domain is configured, all sandboxes created within this domain will adhere to the specific rules of Assembly Lab.
+
+:::note
+Once a domain has been configured as an assembly lab domain, do not try to change it back to a non-assembly lab domain. Assembly Lab domains have a different set of rules for resource management and blueprint resolution which are not compatible with standard domain operation.
+:::
+
+To set a domain to be an Assembly Lab domain, open the [domain's properties page in Resource Management Client](../../cloudshell-identity-management/cloudshell-domains/domains-window.md).
+
+1. Press Edit next to the domain name.
+2. Tick the checkbox Assemble Lab and press `Ctrl+S`.
+
+![configure domain](../../../../static/Images/Admin-Guide/AssembleLab/configure-domain.png)

docs/admin/setting-up-cloudshell/assembly-lab/fixed-devices copy.md

@@ -0,0 +1,12 @@
+---
+sidebar_position: 6
+---
+# Required Actions for Incomplete Work Order Resources
+
+Each work order resource that is not yet complete and has an issue blocking completion will have Required Actions. In the Work Order UI, by clicking on the warning or error indicator, users can see what is blocking completion and, in some cases, remediate the issue automatically.
+
+For example:
+
+If the sub-resource is not part of its parent, you can indicate that you have moved it in the real world and update Cloudshell to reflect that it has been moved.
+
+Since an Assembly Lab involves moving devices in the lab, tracking the "real world" resource structure and cabling is critical. The purpose of the work order is not only to help reserve the right resources but also to indicate changes to the data that reflect what is happening in the lab.

docs/admin/setting-up-cloudshell/assembly-lab/fixed-devices.md

@@ -0,0 +1,13 @@
+---
+sidebar_position: 7
+---
+# Fixed Devices
+
+Administrators can configure devices to not be used as partial solutions in other devices.
+This is done by adding an boolean attribute with the tag *Fixed* to resources.
+
+Make sure to set this value to True for all resources who are never supposed to be used as parts in other resources.
+
+:::note
+Fixed resources can never be solutions for requests that are part of a cable route. This is so they maintain their current setup
+:::

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

@@ -0,0 +1,84 @@
+# Assembly Lab: An Innovative Approach to Dynamic Resource Management
+
+## Introduction
+
+Assembly Lab revolutionizes traditional lab management by introducing a dynamic and flexible system for managing resources and fulfilling orders. 
+
+Unlike conventional labs where the configuration of devices remains static, Assembly Lab enables the fluid movement of sub-resources between different resources to meet specific blueprint requirements. 
+
+The key is to understand the difference between standard Cloudshell blueprint resolution, and Assembly Lab blueprint resolution.
+In the standard mode, the entire blueprint must be solved satisfactorily, or there will be a conflict.
+
+In Assembly Lab, solving the blueprint partially is possible, and it is expected that further changes to the inventory OR to the request (originally a blueprint, but now a pending sandbox) will eventually bring the sandbox to the desired state.
+
+## Assembly Lab Rules
+
+### Route Handling
+
+If there is a route between resources, the route will not be solved (i.e., Layer 1 ports will not be reserved). However, the system will attempt to select resources that are connected to Layer 1 switches.
+
+### Sandbox Creation
+
+A sandbox is always created, even if not all requirements are met. This approach ensures that users can proceed with their projects while resolving outstanding requirements.
+
+### Whole Resource Utilization
+
+As many resource requirements as possible will be solved with whole resources. This approach minimizes fragmentation and maintains the integrity of individual resources.
+
+### Sub-Resource Utilization
+
+If a requirement cannot be met with an entire resource, the system will attempt to solve it using parts drawn from other resources. This flexibility ensures that requirements can still be met even if whole resources are not available.
+
+### Port Matching
+
+If a requirement involves a port (from the "connectable" family), matching the parent resource will automatically match the child resource. Ports will not be drawn from different resources but from within the same resource where they reside. This rule maintains the logical integrity of connections.
+
+### Abstract Resources Modification
+
+Abstract resources can now also be added directly to a sandbox and modified therein. This allows requirements to change during the lifetime of the sandbox.
+
+### Abstract Quantity
+
+:::warning[Quantity in Abstract Resources is not supported for Assembly Lab]
+:::
+
+### Fixed devices
+
+Fixed devices are never selected as parts, only as complete resources. [Read more](#fixed-devices-1)
+
+## Completing Work Order Resources
+
+For a work order resource to be marked as completed, the following conditions must be met:
+
+### Sub-Resource Matching
+
+All sub-resources that match their requirements must be children of resources that match their parent requirements.
+
+### Model and Value Matching
+
+The matching resource must be of the same model as the requirement and have values that are required by the abstract resource.
+
+### Hierarchical Completion
+
+Each of the work order resources in their hierarchy must also be marked as "completed" for the entire resource to be considered completed.
+
+
+### User Interaction and Negotiation
+
+#### Sandbox Interaction
+
+The sandbox environment enables lab managers and customers to negotiate over requirements and make adjustments as needed. This can involve shifting devices around or changing requirements to something more feasible.
+
+#### Capability Sets
+
+User groups can be managed through capability sets, ensuring that each group has the appropriate access levels and permissions.
+
+#### Sticky Notes
+
+Sticky notes can be placed in blueprints and sandboxes to clarify requirements and communicate important information.
+
+#### Work Order Comments
+
+Lab managers can leave comments on each record in the work order, allowing customers to track progress and stay informed about the status of their requests.
+
+

docs/admin/setting-up-cloudshell/assembly-lab/work-order-management.md

@@ -0,0 +1,21 @@
+---
+sidebar_position: 3
+---
+# Work Order Management
+
+In Assembly Lab, work orders are crucial for managing routes and resources within the sandbox. The work order consists of two main tabs: Resources and Routes.
+
+## Resources Tab
+
+The Resources tab maintains a record for each abstract resource or sub-resource. Each record can have a concrete resource that matches it and a "state" indicating its progress (Not Started, In Progress, Completed).
+
+Until each work order resource has a concrete resource that matches the abstract requirement and is marked as Completed, the sandbox diagram will display the abstract resource rather than the concrete resource.
+
+## Routes Tab
+
+The Routes tab displays either cable routes or logical routes used to apply Layer 1 connectivity.
+
+Each record in the Routes tab represents a single route.
+
+- For cable routes (known as "direct" in the work order), if both work order resources at the terminus have been selected, users can apply "connect" to indicate that the devices have been wired together in the lab (or "disconnect" for the inverse).
+- For Layer 1 routes, users can assign the work order resource to be connected to another device in the lab.

docs/admin/setting-up-cloudshell/cloudshell-configuration-options/resource-search-customizations.md

@@ -6,10 +6,10 @@ sidebar_position: 30
 
 Setup Cloudshell to show an attribute directly on search results
 
-![SearchResultsWithAttribute](../../../../static/Images/Admin-Guide/ResourceSearchCustomization/SearchResultsWithLocation.png)
+![SearchResultsWithAttribute](/Images/Admin-Guide/ResourceSearchCustomization/SearchResultsWithLocation.png)
 
 ## Steps:
 
 [Configure an attribute](../../../admin/setting-up-cloudshell/inventory-operations/resource-data-modeling-for-1st-gen-shells/attributes.md) to have the rule *Display On Search Card*
 
-![DisplayOnSearchCardRule](../../../../static/Images/Admin-Guide/ResourceSearchCustomization/SearchCardRule.png)
+![DisplayOnSearchCardRule](/Images/Admin-Guide/ResourceSearchCustomization/SearchCardRule.png)

docs/install-configure/_category_.json

@@ -1,4 +1,4 @@
 {
   "label": "Installation and Configuration",
-  "position": 6
+  "position": 7
 }

docs/intro/features/assembly-lab.md

@@ -0,0 +1,46 @@
+---
+sidebar_position: 14
+---
+
+# Assembly Lab Overview
+
+## Dynamic Resource Management
+
+Assembly Lab transforms traditional lab management with a flexible, dynamic system for resource management and order fulfillment. Unlike static configurations in conventional labs, Assembly Lab allows fluid movement of sub-resources to meet specific blueprint requirements.
+
+### Key Features
+
+1. **Flexible Blueprint Resolution**: Unlike standard blueprint resolution that requires complete solutions, Assembly Lab allows partial solutions. Users can make changes to inventory or requests to gradually achieve the desired state.
+
+2. **Route Handling**: Routes between resources are not immediately solved, but the system tries to select connected resources.
+
+3. **Sandbox Creation**: A sandbox is created even if not all requirements are met, enabling users to proceed while resolving outstanding needs.
+
+4. **Whole and Sub-Resource Utilization**: The system prioritizes whole resources to minimize fragmentation. If unavailable, it utilizes sub-resources from other resources.
+
+5. **Port Matching**: Ports are matched within the same resource, maintaining logical connections.
+
+6. **Abstract Resources Modification**: Abstract resources can be added and modified directly in a sandbox.
+
+7. **Fixed Devices**: Fixed devices are used only as complete resources.
+
+### Completing Work Order Resources
+
+For a work order resource to be marked as completed:
+- All sub-resources must match their parent requirements.
+- Resources must match the model and required values.
+- The hierarchy of work order resources must be completed.
+
+### User Interaction and Negotiation
+
+- **Sandbox Interaction**: Lab managers and customers can negotiate and adjust requirements.
+- **Capability Sets**: User groups are managed with specific access levels and permissions.
+- **Sticky Notes**: Notes can be added to blueprints and sandboxes for clarification and communication.
+- **Work Order Comments**: Lab managers can leave comments on work orders for customer updates.
+
+Assembly Lab offers a revolutionary approach to lab management, enhancing flexibility and resource efficiency.
+
+
+## Related Topics
+
+- [Assembly Labs](../../admin/setting-up-cloudshell/assembly-lab/index.md)

docs/jss/_category_.json

@@ -1,4 +1,4 @@
 {
   "label": "New Job Scheduling",
-  "position": 7
+  "position": 6
 }

docs/release-notes/whats-new.md

@@ -24,34 +24,33 @@ A radically different mode of operation for CloudShell is now available!
 
 #### For more information on Assembly lab, follow these links
 
-- [Assembly Lab Overview](../admin/setting-up-cloudshell/cloudshell-configuration-options/assembly-lab/index.md)
-- [Configure an Assembly Lab domain](../admin/setting-up-cloudshell/cloudshell-configuration-options/assembly-lab/configure-assembly-lab-domain.md)
+- [Assembly Lab Overview](../admin/setting-up-cloudshell/assembly-lab/index.md)
+- [Configure an Assembly Lab domain](../admin/setting-up-cloudshell/assembly-lab/configure-assembly-lab-domain.md)
 
 ### Capabilities
 
 CloudShell's RBAC implementation, you can now associate user groups with capability sets.
 Each capability set can specifically allow or block certain capabilities, overriding the defaults provided by the group role.
 
-[Read more here](../admin/setting-up-cloudshell/cloudshell-configuration-options/capabilities/index.md)
+[Read more here](../admin/cloudshell-identity-management/managing-cloudshell-permissions/capabilities/index.md)
 
 ### Display attributes in Resource Search directly on cards
 
 [Configure specific attributes](../admin/setting-up-cloudshell/cloudshell-configuration-options/resource-search-customizations.md) to appear directly on resource search results.
 
-![SearchResultsWithAttribute](../../static/Images/Admin-Guide/ResourceSearchCustomization/SearchResultsWithLocation.png)
+![SearchResultsWithAttribute](/Images/Admin-Guide/ResourceSearchCustomization/SearchResultsWithLocation.png)
 
 ### Filter sandboxes by user input and display the user input in Sandboxes Dashboard
 
 - Configure an attribute to be displayed in sandbox dashboard
 - Show only sandboxes which passed a particular value
 
-![Sandbox Dashboard Customization](../../static/Images/Admin-Guide/CustomizingSandboxesDashboard/filter.gif)
+![Sandbox Dashboard Customization](/Images/Admin-Guide/CustomizingSandboxesDashboard/filter.gif)
 
 [For more details](../admin/setting-up-cloudshell/cloudshell-configuration-options/customizing-sandboxes-dashboard.md)
 
 ### Minimum Lead Time
 
-Configure a domain to set a minimum lead time for reserving Sandboxes.
-When configured, sandboxes can only be ordered for a future date.
+You now have the ability to establish a minimum lead time for reserving Sandboxes within a specific domain. This means that when this setting is configured, any sandbox reservations must be made for a date in the future, not for immediate use.
 
-To configure it, set MinimumLeadTimeMinutes using [this](../api-guide/cs-admin-rest-api/edit-domain.md) API call.
+To implement this, you need to adjust the `MinimumLeadTimeMinutes` parameter via a specific API call. Detailed instructions on how to make this API call can be found in [this guide](../api-guide/cs-admin-rest-api/edit-domain.md).