PT: 176018998

PT: 175884018

If changes happen to the CF foundation outside of the treeview (e.g. through the CLI, in a different view, from someone else's machine, etc.), the treeview will not update itself (at the moment), so users of our extension might be mislead by the UI if it doesn't accurately reflect the state of the CF foundation.

A "Refresh" button might be a good 1st step toward keeping the view in sync with the CF foundation but the changes wouldn't be automatic

2 ways we might be able to have automated synchronization:

poll the CF foundation on a regular basis & update the tree view to match
use callbacks/hooks into the CF API (possibly using websocket?) to get notified when anything changes

PT: 175520607

PT: 176704566

PT: https://www.pivotaltracker.com/story/show/173963584

Imported from Pivotal tracker: 177105510

PT: 174890558

E.g. "No apps found." instead of "No apps"

Currently the extension comes bundled with a copy of cf.exe for CLI v6, but this version of the CLI isn't compatible with all CF foundations; newer CFs require CF CLI v7.

For users with newer versions of CF, we should also include a cf executable that uses v7 & amend our extension so that it's able to detect which version of the CLI to use for a given CF instance.

This doc describes CF foundation requirements for each CF CLI version: https://github.com/cloudfoundry/cli/wiki/Versioning-and-Support-Policy

E.g. deploying an app with the name "my cool app" will create a new app on the TAS instance with a name of "my"

PT: 175461639

Take a look at how to represent actions in a toolbar, hotkeys, and right-click menus.
What are the standards to follow?
Should we add a local toolbar to the application listing window?

Currently, when the Refresh button is clicked in the CloudExplorerToolWindow, all app/space/org/cf rows in the tree view will begin to update (i.e. request fresh lists of children behind the scenes), but nothing in the window changes immediately. This might lead some users to question whether or not they initiated the refresh properly.

If a refresh button click were to give some visual confirmation that the refresh process has started but is still ongoing, users will almost certainly have more confidence that they're using the extension properly.

For a complex CF foundation (i.e. one with multiple orgs/spaces/apps), rapidly expanding several tree view items can sometimes cause incorrect "children" rows to appear under one or more tree view items. E.g. an org might report having child spaces that actually belong to a different org.

PT: 177164519

Steps to reproduce:

1. have tree view display a row with no children such that the "empty" placeholder child appears
2. give that row children outside of Visual Studio
3. click cloud explorer tool window's refresh button
4. notice that any new children appear under the "empty" placeholder child (placeholder is not removed)

Example:

PT: 175808681

PT: 177104430

The RaisePropertyChangedEvent method on AbstractViewModel only raises an event if the "handler" property is not null. We've occasionally seen this property be null when running unit tests but it should never happen in the wild; if it does it's probably a good sign that we have a bug & we should log any relevant diagnostic info.

PT link

To Replicate:

Open a new VS session with the Tanzu-For-Visual-Studio-Toolkit extension installed
Try to deploy a project from the Solution Explorer: right click Project row > Deploy to Cloud Foundry
Add a new Cloud (CF) connection if there are none via "AddCloud" button (enter login creds)
Log in
Open Cloud Explorer Tool Window via VS menu bar > Extensions > Tanzu Cloud Explorer
NOTICE: the tool window shows a blank tree view (i.e. the Cloud connection we just added during the deployment step above is not shown immediately)
Add a new cloud (CF) connection via "Add Cloud" button (enter creds & log in)
NOTICE: TWO cloud connections are displayed in tree view when previously there were none shown.

PT: 175649992

PT: 175746086

PT: 174074026

Login user/pass should be obfuscated.

When calling the CF CLI from the Extension, we should make sure that the password is not exposed anywhere (console output, debug logging, etc)

PT: 176660359

PT: 175749735

PT: 174916069

At the moment, when adding a new connection to a TAS instance via the DeploymentDialog "AddCloud" button, the tree view does not change automatically to add a new "CF Instance" row; seeing the new connection requires a manual refresh (button click).

It should be possible to have these new connections appear automatically the way they do after being added via the CloudExplorerToolWindow's "AddCloud" button.

PT: 175504480

At the moment, when deploying an app via the Deployment Dialog the output window appears & prints deployment updates but it stays locked to the top of the content window until the user scrolls all the way down (at which point the window automatically keeps scrolling to track the most recent lines of output).

A nicer feature would (arguably) be to have the output window start tracking the most recent deployment output by default (i.e. avoid having to manually scroll down first to see the most recent lines as they get printed).

At the moment, when using the DeploymentDialog window it takes a noticeable amount of time for the orgs & spaces to load for any selected TAS instance in the "Deployment Target" dropdown. When the orgs/spaces haven't yet loaded the dropdowns appear empty which is visually confusing. Adding a "Loading" placeholder item to these dropdowns could help explain why the proper orgs/spaces aren't listed right away.

Our error dialog is very basic at the moment - there's room for improvement in terms of UI.

PT: 175462160

PT: 177047792

The output window needs to support showing each application in separate output windows.

PT: https://www.pivotaltracker.com/n/projects/2458618/stories/176869921

Add a README to the repo with the instructions

PT: 176982067

Currently we're using /C when we invoke cmd.exe; maybe we should consider also adding /D (disable AutoRun commands from registry), and possibly others from this list:

Starts a new instance of the Windows command interpreter

CMD [/A | /U] [/Q] [/D] [/E:ON | /E:OFF] [/F:ON | /F:OFF] [/V:ON | /V:OFF]
[[/S] [/C | /K] string]

/C Carries out the command specified by string and then terminates
/K Carries out the command specified by string but remains
/S Modifies the treatment of string after /C or /K (see below)
/Q Turns echo off
/D Disable execution of AutoRun commands from registry (see below)
/A Causes the output of internal commands to a pipe or file to be ANSI
/U Causes the output of internal commands to a pipe or file to be
Unicode
/T:fg Sets the foreground/background colors (see COLOR /? for more info)
/E:ON Enable command extensions (see below)
/E:OFF Disable command extensions (see below)
/F:ON Enable file and directory name completion characters (see below)
/F:OFF Disable file and directory name completion characters (see below)
/V:ON Enable delayed environment variable expansion using ! as the
delimiter. For example, /V:ON would allow !var! to expand the
variable var at execution time. The var syntax expands variables
at input time, which is quite a different thing when inside of a FOR
loop.
/V:OFF Disable delayed environment expansion.

NOTES:

Other folks probably have opinions about how best to invoke cmd.exe from the Process class in C#; let's see if we can find any useful suggestions online

PT: https://www.pivotaltracker.com/n/projects/2458618/stories/175725285
^ This issue content is: "Have the ability for a user to turn off confirmation dialogs, and any other configuration"

Add a confirmation dialog with the user before they permanently delete (+ save this preference as some sort of config)

PT: 175764005

Now that deployment output gets printed to the Output Tool Window, we might be able to get rid of the extra text box at the bottom of the Deployment Dialog window.

The CF CLI manages 2 auth tokens (it stores them in ~/.cf/config.json):

1. An Access Token with a 2-hour lifespan. When this token expires mid-session, the CF CLI requests a new one from the CF API using:...
2. A Refresh Token with a 2-week lifespan. When this token expires, the CF CLI requires re-authentication (from what I understand)

Our extension currently only performs an authentication request (i.e. retrieval of a new refresh token) when connecting to a new "Cloud Foundry Instance" for the first time. This means that we can expect users of our extension to encounter issues after 2 weeks of using the same "Cloud connection" if they don't manually re-login (and nothing about our extension makes that clear at the moment).

Add a README to the repo with the instructions

PT: 176173178

PT: 174927276

PT: 177023840

PT: 176870115

Currently, when using the CloudExplorer to stop/start/delete an app which has been deleted outside the IDE (i.e. the tree view is not in sync with the real CF foundation), an error window is raised with the message "Unable to stop/start/delete {app name}."

This message could be made more explanatory; it could describe that the reason for the error is that the app didn't exist at the time the start/stop command was issued. In the case of an app deletion, we could improve the UX even further and not raise any error when trying to delete an already-deleted app.

PT: 176175964

PT: 176019071

PT: 177047927