• Create a form to register a user.

sambros: The current pipeline list page needs to update to the latest PatternFly design. This page showcases all the pipelines used within a shared server (ex. you, the user, can view the pipelines used and created in your BCH Radiology department).

npm install output includes over 65 dependency vulnerabilities and some had critical status. Fix the dependencies and clean up the package.lock file.

It looks like the Drop Down in the UI for "All plugins" only shows the first page of plugins returned by the backend.

• Switch the link-to-feed from the far right to simply being able to click on the Feed name/icon on the left. Even after all this time using the UI, my instinct is still to want to click on the left not the right to "enter" a Feed.
• I think the "view feed details" should provide some summary info about the Feed itself, not actually enter the feed explorer. One idea would be to show the high level status (Complete / Success, Complete / Failed, Running) with a link to poll for more running data in table (without having to visit the feed explorer) - other additional data that could be offered: amount of data/plugins?

Sanity checks we should do on add node textarea input for CLI commands:

• check that any path / inputpath type parameters point to files that exist that we can access
• check that all parameters exist for the plugin being used and are spelled correctly, etc

If any error condition is detected, grey out the submit button and throw up an error message.

Right now there isn't a UI-based way to add a new node to a feed. We need a design & front end implementation for this.

Some notes / considerations:

What model do we want to be using for Feeds?

The model we use matters, because it has implications for how the "Add node" functionality will work.

• Instant Apply: Right now the model is, as soon as a plugin is added to a feed it begins processing - so it's an 'instant apply' model.

  • Instant apply is nice in that you don't have to worry about the feed details page being in a "mode" or "state" which can cause confusion for users if it's not super clear what the current state is.
  • If the user makes a mistake that is then instant applied, recovery is difficult - right now it's tricky to implement (for example) canceling a plugin that is currently processing.
  • There could also be an opportunity to overload the system by making a lot of mistakes and spinning up a bunch of plugins by hitting the wrong button multiple times. This could be prevented in the front end maybe through some kind of rate-limiting thing.

• Compose & Play: An alternative model would be a "compose & play" model, where there is a compose or edit mode where you build out your tree, then a "play" mode where you can run it.

  • Compose & play modes introduce a concept of 'mode' which can cause confusion
  • Compose & play enables experimentation and is forgiving of mistakes - you can add / remove / configure nodes at will while in compose mode and not worry about correcting mistakes and without requiring complex functionality to cancel a running operation, and once satisfied with the entire composition can go into play mode and run the node tree.

For MVP, will we allow adding both plugins and pipelines at a new node?

For MVP we will only allow adding plugins, but the design should support adding both eventually.

Handling parameters when adding a node

When adding a plugin or pipeline, parameters may need to be set by the user. Pipelines have default values established for each parameter - plugins don't necessarily have default values for each parameter, and some parameters are required.

We might want to consider presenting the parameters in this order of priority:

• Non-optional / Required parameters with no default values
• Optional parameters with no default values
• Non-optional / Required parameters with default values
• Optional parameters with default values

Here is an example parameter, showing fields from a parameter for the PACSpull plugin:
- { "optional": true, "type": "str", "default": "", "action": "store", "flag": "--PatientID", "name": "str_patientID", "help": "The PatientID to query." }

User workflow for adding a node to a feed

This assumes the instant apply model, which is currently how cube works. If we adopted a compose & play model, only workflow steps 1-5 would be valid, then there would be an additional final step of hitting a 'run' button on the feed to actually run everything.

1. Navigate to the feed you want to add a node to
2. In the node graph for the feed, click on the node that you'd like to be the parent of the new node you are adding (in order to select it.)
3. While the target parent node is selected, click on a 'add new node' button in the right hand panel of the graph view.
4. A floating dialog appears docked to the right side of the screen. It will ask which plugin / pipeline to add, providing searchable lists of plugins / pipelines for the user to choose from. The user clicks next.
5. The second page of the floating dialog is the user's opportunity to fill in required parameters without defaults as well as review the parameters that are optional and/or have defaults in order to provide values for those as well. The user clicks 'add node'
6. The node is added to the graph, greyed out at first. As it begins to run, the node circle begins to pulse to indicate it is processing.
7. The user can at this point opt to add another node to the graph. They can add a node to the processing node as well, but it will be queued until the processing node completes (it can't run because it depends on the output of the processing node.) Queued nodes will show up as greyed out with dashed connector lines to indicate that they are queued.
8. The processing node completes, its circle stops pulsing, and it appears at full opacity on the graph as any other completed node.
9. The next queued child node of the recently completed node will begin to pulse as it processes.

1. Create a DICOM viewer based upon the cornerstone.js library.
2. Implement tooling like pan, zoom, invert and modality.

Needs Grooming** - feed details page has issues with responsive design - the graph gets a bit corrupted and the lefthand menu doesn't stack. If you scale down and rescale up, the divider between the two node graphs gets shifted and overwrites one of the graphs too.

The parameter editor in the process of adding a node does not take in negative values and date in the format "yy-mm-dd".

Working on a fix.

The discussion for the below feature can be found here:
http://chrisproject.org/status-apr-16-2020/

1. Rewrite the Create New Feed feature with hooks
2. Update the fnndsc javascript client to 1.1.1 in the UI.

Data Configuration

Chris File Select

Run an FS Plugin

Add cancel and/or delete buttons per node in feed details. (Cancelling a node also cancels all nodes that follow it in its tree branch)

@xhyzzZ could you fix this. fetch the upstream master, and then rebase your code and run npm test to reproduce.

Currently, incorrect username or password just shows the /not-found page.

Login page should give correct feedback to user about being unable to log in.

Fix broken unit tests for chris ui

This was discussed at the UI meeting @bss in late June.

There is some confusion about how the data in the blue column next to the graph vs. the data in the header bar and the white content area below the graph relate to each other in the feed details page.

Shania's pipeline design uses the header and white content area below only for pipeline-wide details, and only node-specific content (related to the highlighted node) appear in the blue column next to the graph.

The feed design needs to be cleaned up to follow this pattern because the lower white content area is more mixed up than this. One wishlist item we discussed was an embedded output viewer in the content area!

As a ChRIS User, I should be able to create a new feed using the UI.

As a user, I should be able to view a pipeline list in the ChRIS UI.

A section of the ChRIS UI in the design that has not yet been implemented is the library, which allows users to search PACS for data to save to their ChRIS storage and to use it in analyses (feeds with plugins). We need the UI for this PACS search in the ChRIS UI to be implemented.

@RPienaar wrote a JS client which should be instructive in implementing the GUI inside of ChRIS:
https://github.com/FNNDSC/pfdcm-drive

This is a WIP mockup of the basics of how the screen should be set up and where in the UI navigation it would reside:

add it as another field to display the description in the top header.

Similar to the feed details page, the pipeline details page will display relevant information to a particular pipeline.

How will the cards look in a mobile view?

The main UI observation here is wiring up the "enter" key:

Configure Form:

• Add subtext: Use the "Add more parameters" button to add command line flags and values to the plugin. Note, if you prefer a free form input box where you might all the command line parameters together, you can safely hit "next" here.
• Wire up "enter" to automatically give a "choose a parameter" dropdown.

Right now there isn't a UI-based way to create a new feed. We need a design & front end implementation for this.

All feeds currently start with a dircopy, but they dont necessarily need to. On the wishlist is a local file upload feature, so you could upload files from your local system to ChRIS and start a feed with those.

So I think this indicates that we should keep the create feed form as lean as possible. Instead of having PACSpull parameters in the 'create a feed' form to kick off the feed, the PACSpull (or file loading) node creation would be a second step after the initial creation of the feed. This way we can support both PACSpull and other plugins starting a feed.

On second thought after starting to mock this up, I concluded that including configuring the fs plugin to have data hooked up to the feed as part of the feed creation process would result in the best user experience. These types of plugins are different than the image processing ones and it would be confusing for the user to understand that they can only start off the feed with a small subset of all the plugins available. It would introduce a lot of error conditions we'd have to handle. I think it's better to take care of that initial plugin for them as part of the feed creation process so they will be ready to go to add whatever plugin from the full set that they would like to.

Also based on discussion I learned we don't really have functioning PACSpull at the moment, so for MVP this design focuses only on file upload + selecting files from the logged in user's ChRIS home directory.

The left side patternfly navbar in the main ChRIS UI would be handy to have the ability to iconify or minimize. Patternfly has some built-in functionality for this so we should turn it on. For screens such as the pacsquery screen where you are working with data with a lot of fields, the extra screen real estate would be really valuable.

As a user I should be able to add a node to an existing feed.

Here is the latest mockup for the screen showing the details of one feed (note that some cards in the pipelines on the bottom are minimized, some are maximized):

Main feed details page

Some points:

• The main navigation mechanism within the page here is the graph. Click on a node, and actions related to that node appear in the right side panel, and metadata / output for the node appear in a large card below.
• Two special cases to the above - the root node in the graph will not have the 'share this pipeline' button, and neither will any leaf node in the graph.
• When "Add new node(s)" is hovered, a new node appears in the graph diagram on the left. It disappears when button focus is lost.
• In the sidebar nav - this is under "my feeds". The previous screen is a listing of all feeds the user created (some marked private, some marked shared). The "feeds shared with me" is a listing of feeds created by other users that have been shared with the logged in user. "My Dashboard" isn't defined yet and may go away.

Dialog: Run pipeline

WIP

(@abdullahsikder)

The COVID-Net UI works in Firefox and Chrome, but it is still typical for Internet Explorer to be in use at hospitals. We may want Microsoft Edge testing too.

It would be very helpful to have an idea of how this UI performs in IE and to create issues found so we can get them fixed.

This is the repo for the COVID-Net UI:
https://github.com/darwinai/covidnet_ui

There is a readme file on the bottom of the front page of the repo that walks you through how to stand up the system.

Issues discovered can be filed here:
https://github.com/darwinai/covidnet_ui/issues

This repo will help you set up the UI with sample data:
https://github.com/darwinai/covidnet_integration

provide private routing protection for pages that require a login to view such as dashboards, etc.

We could start doing this for the store first and then the main ui

cc @rebecabkerr

Upgrade to new back end api v 1.1.4 here: https://github.com/FNNDSC/fnndsc

new api:

• plugins can have same name with different versions

• modify plugin api changes

cc: @jbernal0019

Design here: https://github.com/FNNDSC/ChRIS_ui/projects/4#card-21576966

We need a list in the UI that shows a list of all of the feeds the logged in user has ownership over.