Users should be notified when things have happened, such as the data has successfully synced, or if there is an error.

Add the ability to edit properties in the detail view of a particular Step.

• Load properties
• Add ability to save new properties
• Populate fields with existing values
• Validation

As a user I want to be able to select the type of workflow I am generating (Camel route, Kamelet, Kamelet Binding,...).

Implementation details

The API can provide multiple DSL formats on the /integrations/customResources endpoint. There should be some way the user can select which one of all those source codes they want to use.

Swagger is a bit lazy, but the response is a Map that returns all possible source codes with a key that represents what the source code is for (on our current case, "Kamelet" or "KameletBinding").

currently there is no color syntax, it is written in white on black

As a user, I'd like to extend or embed Kaoto using a package published on the npm registry, and have access to the relevant typings (IKaoto).

As a user, I would like the ability to run part of an integration for testing and debugging purposes.

Relates to #12 , since using dummy data could be an option if the integration has not been deployed yet. However, we should consider options for deployed integrations as well.

We should be automatically generating the fields for the parameters object that contains configurable properties for a particular step.

• https://github.com/vazco/uniforms
• https://github.com/aerogear/uniforms-patternfly

As a user, I would like to have the ability to decide whether the code editor is visible. This should persist even when refreshing the page.

Right now if you close the editor and refresh the page, the editor reappears (src/components/YAMLEditor.tsx). We should persist these changes to localStorage or similar.

As a user, I would like to know where I can drag and drop steps so that I can update the YAML integration from the visualization.

The UI should be "smart" enough to let users know what kind of step should be allowed in a specific area of the integration. Zimara's UI would benefit from a kind of validation service to help guide the user in planning and creating their integrations within the visualization.

Steps

• Plan validation logic from user behavior perspective
• Slot creation service
• Create slots on building integration from YAML
• Add validation logic
• Presentation of validation

As a user, I would like to be able to add a new step to the visualization, in a new area currently not used by an existing step.

• #144
• #154
• #117
• Handle empty state and deleting a Start step
• #218
• #219

As a user, I would like the ability to reuse fields from one Step in another, in order to be able to make more useful integrations.

ie new product listing -> create a banner with it or social media post

Example:
User creates a product on Shopify. News of product creation is automatically shared on Twitter and a Telegram channel with the message "Hey there, my design is now on a new product. Visit my {shop_name} to get this cool {product_name} and check out more {product_category}! {shop_link}". You can make the message even more appealing by adding a Bannerbear node that automatically creates template images for your new product announcements.

Create a PoC to demonstrate the Step Extension functionality of extending the UI with a partial view.

As a user, I would like the ability to replace an existing step in the visualization with either a step from the catalog or a temporary/freestanding step.

• Ability to replace step with "temporary" step (Konva node)
• Ability to replace step with catalog step (DOM element)
• On select, bring group forward

This will probably need some additional aesthetic enhancements.

Depends on #117 .

This page https://kaoto.io/docs/add-custom-view/ should have more details so we can have newcomers develop extensions easily.

The ability to search through the Step (Kamelet) catalog and sort.

Right now you need to click on the icon itself, despite drag and drop being enabled for the entire Group.

The API already supports deployment management. We need some way to start, stop, and list integrations after finishing the editing.

Implementation Details

The cluster configuration is taken from ~/.kube configuration.

Recommended quick setup for testing:

• Install kind https://github.com/kubernetes-sigs/kind
• Install camel-k https://camel.apache.org/camel-k/1.7.x/installation/kind.html

The user interface must implement the following:

• Start a new integration using POST on /integrations
• Stop an existing integration (from the previous list?) using DELETE on /integrations

Related backend task: KaotoIO/kaoto-backend#19 and KaotoIO/kaoto-backend#10

As a user, I would like to be able to combine several smaller integrations from the visualization, into a single "parent workflow", in order to be able to reuse integrations as much as possible and to encourage creating smaller integrations.

Add the ability to insert a new Step between two existing Steps from the Visualization. There are two ways the user should be able to do this:

• The user clicks a "+" button on the last step, which inserts a slot between the two steps. The user can then drag a step from the Catalog onto the slot.
• The user clicks a "+" button on the last step, which inserts a slot between the two steps. A mini catalog (#216 ) opens up, and the user can then choose the step to be aggregated/appended.

It's not entirely clear if both ways will be possible or intuitive to the user. A story should be created for each to see which option would be best to start with.

See this issue for more information: #218 <-- we should be following the same decision for both ways of adding a step

Steps

• Add validation for inserting a step
• Add custom edge
• Implement changes onto Visualization

Description

This is an EPIC to add support for branching in the Visualization.

Depends on #193 and #270 <- this must be complete before branching can be fully implemented, though development can start before then.

Business Requirements

• Branches can be started from any step (e.g. START, MIDDLE, END)
• There can be more than one branch from a single step
  • For example, with a CHOICE step, it's like if/else, so there will automatically be two branches, depending on the outcome of the condition
  • We don't yet support a "default flow" and "alternate flow", so the branches should each be equal weight in priority
• Branches contain steps, and those steps can be type MIDDLE or END
• If it's of type MIDDLE, then it should be merged back
  • Maria: It can merge back to any step, MIDDLE and END (well, I guess not START)
  • Just merged to the following step to that EIP unless it finishes in an END
  • Though not the most common scenario, it should be possible to have one branch that ends in END, and one branch that ends in MIDDLE and gets merged back

Tasks

• #782
• #785
• #784
• #783
• #1158
• #786
• #1240

Add the ability to append a step to the last step in the integration from the Visualization. There are two ways the user should be able to do this:

• The user clicks a "+" button on the last step, which appends a slot onto it. The user can then drag a step from the Catalog onto the slot.
• The user clicks a "+" button on the last step, which appends a slot onto it. A mini catalog (#216 ) opens up, and the user can then choose the step to be aggregated/appended.

It's not entirely clear if both ways will be possible or intuitive to the user. A story should be created for each to see which option would be best to start with.

There is also a third way that is dependent on support for temporary steps (steps on the canvas that are not a part of the integration):

• The user drags and drops a step from the Catalog onto the canvas (not onto an existing step). The user then connects the arrow from the existing integration to the temporary step. The YAML syncs and the temporary step is now a part of the integration.

Since we've removed support for temporary steps for now, this option is not possible, but I'm leaving it on here for future reference anyway in case we add temporary steps again.

Relates to #219 <-- the same decision should be used for both

Steps should have a clear, separate label that indicate whether they are sources, sinks, or actions, possibly only showing the connector name in the main label.

Example:

Add support for a "mini catalog" that loads a list of steps. The idea is that when a user wants to add a new step to an existing step, they will click a + button that loads a searchable mini catalog of steps compatible with it. The user can then select the step, which will automatically be appended to the existing step.

Steps

• Update apiService to use new endpoint
• Add component for Contextual Mini Catalog
• Add handler for selecting steps
• Verify validation is in tact, add tests
• Add search

Depends on KaotoIO/kaoto-backend#42 and either #218 or #219 for the final implementation, but development can start before then.

Tasks:

• Set up E2E framework, likely Cypress
• Define happy path
• Add tests for happy path

As a user, I would like to have a list of common workflows that can be used as a template, which would save time in setting up integrations or getting more familiar with how to use Kaoto.

Similar to how most workflow processing apps work, like LucidChart.

Example: New order in Shopify -> create Salesforce contact -> create Trello card

Users should either 1) see the steps available in the catalog in alphabetical order, or 2) be able to sort them as they choose to.

Clicking on a step in the visualization canvas should display properties available for it. In the future, these properties will be editable.

• Ability to delete temporary step (not connected to an integration)
• Ability to delete middle step of an integration

Ability to be notified when an integration has started running or finished running.

• Set up unit test library with typings
• Add coverage checks
• Add linting
• Add tests for primary components
• Verify build
• CI/CD

The current debounce setup is causing the cursor to jump around quite a bit if you edit the YAML too quickly.

It should be apparent to users that there is a start and and end of an integration in the visualization.

Intended Result (Chrome):

Actual Result (Firefox):

We need some kind of tutorial/walk-thru that users could refer to when first using the app, that can also be referred to later on by just clicking a button.

The user drags and drop steps from the catalog into the graphical editing canvas to add new steps.
The user then edits the properties of the step.
The user can reorder the steps.
The user can replace existing steps with others from the catalog.

• #144
• #8
• #145

There is a new bug with the slot replacement after Append Step was added.

Steps to reproduce:

1. Create a multi-step integration using the YAML editor, or use the one loaded by default.
2. Delete the first step (source).
3. Open the catalog.
4. Drag a source step onto the "Add Step" slot.

The UI breaks, see screenshot below.

Also, we should add E2E tests to ensure this doesn't happen again.

The current step extension example is pretty awful, it would be good to see this improved a bit, maybe with a form or something.

Something like a + button hidden away on the side, and when the user presses it, it opens up the catalog. The idea behind this is that the user won't be using the catalog very much once their integrations are set up. Can follow up with some UX designs if it'd help.

As a user, I would like to be able to predict the output of an integration up to a particular Step or series of Steps by seeing their output using dummy data based on their specification, which would help test the execution of those Steps as a form of debugging.

Use cases:

• Improving the general developer experience, debugging assistance
• Easier planning of integrations
• Generating data for previewing custom views, or Step Extensions
• Generating data to be used for testing

Description

When the YAMLEditor (code editor) is selected, the Catalog should be collapsed, and vice versa. This would prevent them from being overlapped, which makes the YAMLEditor unusable when the Catalog is opened.

We can't move the Catalog to the right side of the screen, because that's where the StepDetail panel is.

This could also be a good opportunity to move the YAMLEditor into the PatternFly Drawer, instead of being part of the Grid system it's in now. This is what the Catalog does--it opens up as an overlay above the Visualization. This allows you to open the Catalog without it moving the Visualization canvas.

The YAMLEditor, using the Grid system now:

By contrast, when using a Drawer like the Catalog does, it's an overlay and doesn't alter the position of the Visualization canvas when it's opened.

Steps

• Add conditional to DrawerContent to show either the catalog or code editor
• Move the code editor into the conditional
• Adjust the Grid for the Visualization, or remove it altogether if it's not necessary.

References

• YAMLEditor using the Grid system
• Catalog using Drawer & DrawerContent
• PatternFly Drawer

In theory, it may be beneficial to have only a set of pre-defined Steps that are constrained, which is what would determine whether or not it's part of an Integration and make it easier to have validation.

When the Step in the YAML is not valid, the API begins to return an empty array for the Views. The visualization, as a result, does not update the integration. The UI should do the following:

• Show the user a warning about there being an issue with a Step they selected (in the YAML editor)
• Update the integration in the visualization and show a Step placeholder where the Step is null

As a user, I would like the ability to change the order of steps by "swapping" positions with one another. This would mean that I would not have to re-configure each step if I decided to change the ordering.

Depends on #117

EDIT: Moving this to be a feature idea, as it seems like an uncommon behavior.

As a user, I would like to be able to upload a YAML file either directly from my computer, or specify a URL to fetch the YAML file from. This would save having to open a YAML file, and copying and pasting the contents in the code editor.

As a user, I would like to be able to view an activity list for a particular integration which shows the state at the moment it was executed. This would be an additional form in debugging in addition to #16 and #12 . NOTE: This is not the same as showing logs for deployments (#311 ).

We want the user to be able to interact with the cluster with the following features:

• List available integrations already running in the cluster
• #55
• Deploy an integration created on the editor
• Stop an existing running integration.
• #19
• #192

All these leveraged through Camel-K to simplify the implementation.

As a file or whatever

Ability to show/hide a particular view (e.g. YAML editor) with configuration settings? For example, if they don't want to override it with a custom view, they just want to hide it. We can use localStorage for this, doesn't have to be some persisted setting in metadata.

EDIT: Considering hiding the YAML Editor by default as well.

As a user, I would like to be able to provide a custom view that would appear in the dropdown App menu as another link (displayed in a modal as shown below).

This generic extension can help developers customize Kaoto to show relevant information outside of the integration. For example, it can show some tutorial or guidelines to help users create an integration, a list of available databases and what to use them for, a list of potential services to connect to,...

Which would open in a modal like this: