Service Dialogs & Dynamic Forms

Relevant source files

The following files were used as context for generating this wiki page:

• app/models/dialog.rb
• app/models/miq_request_workflow.rb
• app/models/service_template.rb
• product/dialogs/miq_dialogs/miq_provision_dialogs.yaml
• product/dialogs/miq_dialogs/miq_provision_google_dialogs_template.yaml
• product/dialogs/miq_dialogs/miq_provision_amazon_dialogs_template.yaml

Introduction

Service Dialogs and Dynamic Forms represent the primary mechanism for capturing user input during the provisioning and reconfiguration of services, virtual machines, and other resources. These dialogs are structured, hierarchical components that define the user interface elements, validation logic, and default values required to fulfill a request. They bridge the gap between user intent and the automated workflows that execute the actual provisioning logic.

The system supports a wide range of field types—including text boxes, drop-down lists, and tag controls—often populated dynamically via Automate methods. Service Dialogs are tightly integrated with ServiceTemplate and MiqRequestWorkflow classes, ensuring that user inputs are correctly mapped to request options and validated before execution.

Architecture and Data Model

The Service Dialog architecture is built upon a nested hierarchy of models designed to organize fields into logical groupings and tabs.

Component Hierarchy

The structure of a dialog follows a clear parent-child relationship:

1. Dialog: The top-level container representing the entire form.
2. DialogTab: High-level divisions within a dialog, allowing for grouped navigation.
3. DialogGroup: Sections within a tab that cluster related fields.
4. DialogField: The individual input elements (e.g., strings, integers, buttons).

The following diagram illustrates the structural relationships between these components:

Data Model Summary

Field	Description	Type
label	The display name of the dialog or component.	String
name	The internal identifier (aliased to label in Dialog).	String
buttons	Defines which buttons (e.g., Submit, Cancel) are visible.	String
system	Flag indicating if the dialog is a protected system-level resource.	Boolean
content	Virtual attribute providing a serialized Hash representation.	Hash

Sources: [app/models/dialog.rb:11-17](https://github.com/datacosmos-br/manageiq/blob/9e90a9f9edc058160915323117bc7e9cdcda0636/app/models/dialog.rb#L11-L17), [spec/lib/task_helpers/exports/service_dialogs_spec.rb:10-18](https://github.com/datacosmos-br/manageiq/blob/9e90a9f9edc058160915323117bc7e9cdcda0636/spec/lib/task_helpers/exports/service_dialogs_spec.rb#L10-L18)

Dialog Lifecycle and Seeding

Dialogs can be defined in YAML files and imported into the system. This is commonly used for providing "seed" dialogs for specific providers (e.g., Amazon, Google, Red Hat).

Seeding Process

During system initialization, the Dialog.seed method triggers the DialogImportService to scan for YAML files within plugin directories.

• Pattern: {,*/**/}*.{yaml,yml}
• Directory: content/service_dialogs (Plugins)

Sources: [app/models/dialog.rb:2-5, 20-28](https://github.com/datacosmos-br/manageiq/blob/9e90a9f9edc058160915323117bc7e9cdcda0636/app/models/dialog.rb#L2-L5)

Example Provisioning Dialog Structure

YAML definitions specify the button layout, tab (dialog) order, and individual field configurations.

:name: miq_provision_amazon_dialogs_template
:dialog_type: MiqProvisionWorkflow
:content:
  :buttons:
  - :submit
  - :cancel
  :dialogs:
    :requester:
      :description: Request
      :fields:
        :owner_email:
          :description: E-Mail
          :required: true
          :display: :edit
          :data_type: :string

Sources: [product/dialogs/miq_dialogs/miq_provision_amazon_dialogs_template.yaml:1-50](https://github.com/datacosmos-br/manageiq/blob/9e90a9f9edc058160915323117bc7e9cdcda0636/product/dialogs/miq_dialogs/miq_provision_amazon_dialogs_template.yaml#L1-L50)

Workflow Integration and Dynamic Population

Service Dialogs are heavily utilized by MiqRequestWorkflow and its descendants to manage the input phase of a request.

Dynamic Field Values

Fields often rely on the :values_from attribute, which identifies an internal method to call for populating options. For instance, allowed_instance_types or allowed_cloud_networks are called at runtime to provide the user with valid selections based on their current context (e.g., the selected Provider).

Field Validation Logic

Validation occurs on both the client side and the server side. The MiqRequestWorkflow#validate method iterates through all dialog fields to ensure:

1. Requirement Check: Fields marked as required: true contain data.
2. Data Type Check: Input matches the specified :data_type (e.g., Integer, Float, Boolean, or Array).
3. Method-based Validation: Custom logic is executed if :required_method or :validation_method is defined.

Sources: [app/models/miq_request_workflow.rb:103-138](https://github.com/datacosmos-br/manageiq/blob/9e90a9f9edc058160915323117bc7e9cdcda0636/app/models/miq_request_workflow.rb#L103-L138)

Service Template Associations

Service Dialogs are linked to ServiceTemplate objects via ResourceAction. This allows different dialogs to be presented for different actions such as Provision, Retirement, or Reconfigure.

Action	Purpose
Provision	Captured when initially ordering a service.
Retirement	Captured when a service is being retired (often contains warning options).
Reconfigure	Captured to modify an existing service's parameters.

Sources: [app/models/service_template.rb:250-265, 435-455](https://github.com/datacosmos-br/manageiq/blob/9e90a9f9edc058160915323117bc7e9cdcda0636/app/models/service_template.rb#L250-L265)

Reconfiguration Flow

When a user reconfigures a service, the system retrieves the reconfigure_dialog through a specific workflow. This process involves serializing the dialog fields while injecting the existing values from the service's options[:dialog] hash so that the form is pre-populated.

Technical Summary

Service Dialogs provide a highly flexible, metadata-driven approach to user interface construction within the project. By decoupling the form definition from the core engine, the system allows for provider-specific customizations and dynamic runtime behavior through Automate integration. The hierarchical structure of Dialogs, Tabs, Groups, and Fields ensures that complex provisioning data can be organized logically and validated rigorously.

Sources: [app/models/dialog.rb](https://github.com/datacosmos-br/manageiq/blob/9e90a9f9edc058160915323117bc7e9cdcda0636/app/models/dialog.rb), [app/models/miq_request_workflow.rb](https://github.com/datacosmos-br/manageiq/blob/9e90a9f9edc058160915323117bc7e9cdcda0636/app/models/miq_request_workflow.rb), [app/models/service_template.rb](https://github.com/datacosmos-br/manageiq/blob/9e90a9f9edc058160915323117bc7e9cdcda0636/app/models/service_template.rb)