Currently the onSearch prop of the <TreeView> is not connected to anything. Related to #38, since this will involve filtering the same generated tree items based on the search state before passing them into the TreeView.

Also weirdly, pressing the enter key while focused in the search bar expands/collapses the tree, not sure what's going on there. We'll want to address that too somehow.

Create a page for the network mapping step in the plan wizard. This will involve conditional components displayed via a radio button.

• Implement the radio button conditional
• Add Title markup & body copy
• Create placeholder for the create network mapping component
• Create placehodler for the select existing network mapping component

Since we separated out network mappings from storage mappings we don't need the "xxx mappings" count column in the tables. User can see mapping details by expanding the whole table row. Updated mockups here: (https://docs.google.com/presentation/d/1xpOlK_OpCDAnylVEL7bNH_UIRsEx89N1wfZKHVQySbk/edit?usp=sharing) Slides 22 and 25.

We'll need to make our CR CRUD requests directly to the k8s REST API, so we should reuse the client code @eriknelson wrote for MTC. This issue is to track pulling it in here once it is moved to https://github.com/konveyor/lib-ui.

Mockups: https://docs.google.com/presentation/d/1YtiJKf5FyDhBf_eIc6pXbHloCSidDmBKATgYXRtPh-o/edit#slide=id.g8b7ac84433_0_57

Originally this was designed as a drag-and-drop tool, I want to try something simpler before we get too far with that plan.

It seems like Select triggered from SimpleSelect is simply ignoring aria-label which is propagated via ...props.
I tried to force by adding aria-label explicitly to Select component with the same result

serious: ARIA input fields must have an accessible name https://dequeuniversity.com/rules/axe/3.5/aria-input-field-name?application=axeAPI index.js:216
Element:  
<ul id="target-provider" class="pf-c-select__menu" role="listbox">
index.js:114
HTML: <ul class="pf-c-select__menu" role="listbox" id="target-provider"> index.js:122
Fix any of the following:
  aria-label attribute does not exist or is empty
  aria-labelledby attribute does not exist, references elements that do not exist or references elements that are empty
  Element has no title attribute or the title attribute is empty react_devtools_backend.js:2273:24

​
To reproduce:
Use any component calling SimpleSelect and make sure aria-label prop is define in the SimpleSelect call.
For example use AddEditMappingModal and then in debug mode (dev tools) click on any select field, the error should appear in console.

We need a grouped read-only view of the mapping "box-and-arrow" visualization. We can reuse some of the structure from the grouped variant of my mapping builder that we abandoned (#24), so I have a good sense of how to do this, I'll focus on it next.

The hosts table has columns for Network, Bandwidth and MTU, and there is an operation to set the selected network for a host. @jortel do you know how/where we would get/set this data in the API? Currently I see how to get the networks on each host, but no notion of a "selected migration network" and no Bandwidth or MTU values.

Relevant mockups:

Not sure if this is necessary, but it might be nice.

This is just a placeholder issue so I don't lose track of this. @ibolton336 @eriknelson

Similar to cam, we will need a way for a user to accept expired self-signed SSL certificates.

Right now, the .env file contents are statically replaced by webpack at build time wherever they are referenced in the source. This means you can't change the API URL on a deployed build, you'd have to rebuild it.

We need to do something similar to the MigMeta object in MTC and ship the value of REMOTE_API_URL to the client at run time via the Express server.

Create a page for the storage mapping step in the plan wizard. This will involve conditional components displayed via a radio button.

• Implement the radio button conditional
• Add Title markup & body copy
• Create placeholder for the create storage mapping component
• Create placehodler for the select existing storage mapping component
  

I think this was carried over from CAM code. @vconzola can you confirm whether we want this?

1. Develop the scaffolding for the PF4 wizard component for adding a migration plan.
2. Build the general form component & all related inputs. Reference the provider form work that @mturley has done to establish consistency across the virt-ui app.
   https://docs.google.com/presentation/d/1YtiJKf5FyDhBf_eIc6pXbHloCSidDmBKATgYXRtPh-o/edit#slide=id.g889039b713_0_75
   

According to @redallen we should be importing our icons like this:

import CogIcon from '@patternfly/react-icons/dist/js/icons/cog-icon';

instead of:

import { CogIcon } from '@patternfly/react-icons';

As-is, we're bundling and shipping all of those SVG icons in our app no matter which ones we use.

We should also add https://github.com/patternfly/patternfly-react/tree/master/packages/eslint-plugin-patternfly-react to catch these issues in the future.

The notification that appears the first time a user sees the Providers table telling them the benefits of uploading to cloud.redhat.com should have this text, "You can analyze your VMware provider data with the Red Hat Migration Analytics service. Migration Analytics generates a complete inventory of your VMware environment and VM recommendations for migration. Select your VMware providers and download the data file. Then log in to cloud.redhat.com, select Migration Analytics, and create a Migration Analytics report."

Depends on #73. Helper functions exist already for populating the MappingBuilder from API objects, but we'll need to change our mapping mutation hook to support updates.

Per Avital, the page heading should be "Welcome to the Migration Toolkit for Virtualization". Need to add "the".

Currently this is not possible due to a limitation of the PatternFly TreeView. This needs to be solved in PatternFly itself, but I'm opening this issue so we remember to follow up and add that support here once it is available.

The table and modal be empty for now. Just need a basic outline

Currently all of our react-query queries can return an isError property (or status === 'error') but don't return any information about the error itself. We should determine if/where error messages can be returned and put them on the page.

Mockups: https://docs.google.com/presentation/d/1xpOlK_OpCDAnylVEL7bNH_UIRsEx89N1wfZKHVQySbk/edit#slide=id.g8b7ac84433_0_15

We need to add MTU and bandwidth info to these options.

As a user I would like view additional migration details so that I can see an aggregate view of migrations associated with a migration plan with relevant status information.
This view includes an expandable PF table component filled with migration items. Rows should be filterable, sortable, and contain an actions section with a kebab and action buttons. Row columns migration name, start time, end time, data copied, & migration status. The status progress pipeline component & status implementation details should be left for another PR.

As a user I would like to view an individual plans migration progress so that I can determine the current status of a given migration/plan status.

This view includes a PF progress bar with several states derived from the plans underlying migration data. This component should be somewhat modular so that it can receive status information via props & change the components text, icon, & progress bar color accordingly.

In #53 we only added validation using useFormState to the Add Provider form. We should put it in all the other forms we have so far (mappings, host network selection, plan wizard steps, ???)

Following is exhaustive list of forms, checked one are using useFormState:

• AddProviderModals - Providers
• PlanWizard - Plan migration wizard
• SelectNetworkModal - Host Network
• AddEditMappingModal - for Network and Storage mappings
• MappingForm - for Network and Storage mappings from Wizard Plan

Create the empty state & parent component for the "Plans" view. This page will display an empty state when no plans are currently loaded into the UI.

https://docs.google.com/presentation/d/1YtiJKf5FyDhBf_eIc6pXbHloCSidDmBKATgYXRtPh-o/edit#slide=id.g878b3b7f84_0_68

I'm not sure what this filter logic will look like, or whether we'll need to change any backend stuff to support it.

Since we're getting closer to our deadline, it might be time to start thinking about this. Could definitely use your help, @eriknelson .

I was thinking we'd need to use Context to lift the form state for wizard steps, but that complicates TS types (the consumer can't tell what form you're passing in since you could be using it for any provider, so we'd need generics and explicit form field interfaces there). I think instead we can just pass the form state objects directly into the wizard steps.

Leaving this out of #66, let's add it as a follow-up. To the left of the Create button there should be a FilterToolbar (driven by useFilterState) to allow the user to filter by a few columns.

@vconzola which columns should we able to filter on here? I'm guessing all of them except number of VMs?

Similar to #35, we will need a change in PF to support this since we can't modify the header of that column (it's generated by the expandable transform in Table). Will open an issue there and follow up here.

Once it's available, as noted here we can use the selectAll and areAllSelected values from useSelectionState to drive this button, and it should use the <AngleRightIcon> and <AngleDownIcon> icons depending on its state.

The status column in the providers table will currently only display the first condition in the list, and hasn't been tested with error or warning conditions. We need to double check that stuff, and possibly look at the rest of the conditions array to identify the most serious condition or display multiple conditions.

See: https://github.com/konveyor/virt-ui/blob/2bf0b914669a79553bad324759b1985bd62a8e29/src/app/Providers/components/ProvidersTable/VMware/VMwareProvidersTable.tsx#L43

I figured we should have an issue like this to remind us that we currently aren't doing any form validation. At some point soon we should investigate solutions for this, and break down tasks for each form we need to add it to.

The label after "URL" needs to be "Service account token".

I think we need to add some missing labels to fix this.

Depends on #72

This has strange recursion implications because of the need to represent a subtree's selection state based on the selection of its descendants. We can reference the implementation in this example on patternfly.org, possibly modified to work with our useSelectionState hook, but we may need to modify that hook to support selecting multiple items (a subtree) at once synchronously.

In order to do this, we should also define our TreeViewDataItems declaratively as a function of API data and selection state, instead of mutating the tree items directly when selection state changes. This may require traversing the tree structure more than once.. I started brainstorming that here: #21 (review)

This won't have a place to live until we get to the drill-down plan details page, but we'll need a special custom component for the little dots-on-a-line progress summary in the table.

This guy:

I think it'll be fairly simple, I'm thinking just a flex container with evenly spaced icons, and a backdrop div (lower z-index) with a top border and padding equal to half the height minus half the border width, for the line through them.

Create a page for the VM selection step in the plan wizard. This will involve 2 nested steps for Filter VMs and Select VMs.
Include necessary title markup & placeholders for the Filter VMs component and Select VMs component.

We should move host details from a row expansion under providers to its own page that can be drilled down to from the providers page. Reasons: scaling - we need to support 50 or more hosts on a single provider and row expansion does not work well.

The issue that kept me from using the PF Table's onSelect prop was that the expanded content had a phantom column that we couldn't control, to the left of our expanded content. I'm not sure if I missed this before, but we might just be able to use the fullWidth: true property in the expanded rows, as in this example to get around the issue. This would also fix the awful layout these tables have on mobile viewports.

@vconzola should we maybe show a popover indicating why the button is disabled?

Storage classes are a separate resource keyed by provider, we can't fetch all of them at once. So we need a storage classes query that depends on the providers query and gets storage classes for a certain provider. This will be used in the expanded content of the OpenShift providers table and in the mapping builder.

As a user I would like to view created migration plans so that I can see an aggregate view of current plans with relevant status information.
This view includes a PF table component filled with plan items. Rows should be filterable, sortable, and contain an actions section with a kebab and action buttons. Row columns plan names, source, target, vm count, & status. The status progress bar component & status implementation details should be left for another PR.

Currently this is not possible due to a limitation of the PatternFly TreeView. This needs to be solved in PatternFly itself, but I'm opening this issue so we remember to follow up and add that support here once it is available.

When using mikes useSelectionState hook, the isEqual function (used to check for selected state in an immutable data structure https://konveyor.github.io/lib-ui/?path=/docs/hooks-useselectionstate--checkboxes) needs a unique ID to check against. We should move to UID's here. This will require deciding how we want to generate UIDs for providers, plans, and mappings mock data until we have real data from the api.

Discussing form validation with @vconzola, we realized there may be a few things we want to warn the user about actively before they proceed to the next step (e.g. open a modal that says "not all source datastores were mapped, are you sure you want to proceed?")

In order to prevent having a modal on top of a modal, we decided we should convert the plan wizard into a full page. This is low priority though, we can have a modal-in-a-modal in the meantime if we need to.