Vscode-extension-for-zowe: Create New Connection needs to work with other profile types

[phaumer]

The current Create New Connection UI is hard-coded for z/OSMF only. To support the Extensibility API it needs to support other types of profiles such as zFTP dynamically as each profile type will need to ask different questions to the user.

This can be done by generating the prompts based on the meta data stored with each profile folder (e.g. ~/.zowe/profiles/zosmf/zosmf_meta.yaml for z/OSMF). These files have all the information needed, including the text strings that describe each property.

We propose he following changes:

• Re-implement Profiles.ts to support MVC principles:
  
  
  
  • a model for reading and updating the profiles
  
  
  • a view to render the user prompts dynamically
  
  
  • a controller that reads the meta-data of the type requested and drives the control flow between view and model
  
  

[phaumer]

https://github.com/JillieBeanSim will help with implementation

[jelaplan]

I'm wondering if all fields in the meta data will appear as questions in the quick pick? We may want to have some fields that are used in CLI but not appear in the Zowe Explorer quick pick.

[jellypuno]

@dkelosky @jelaplan do we need to consider this change in profiles with tokens?

[phaumer]

@jelaplan I agree that the text in the meta-data might not always match well, but I see this as a quick fix to get the other profile types working.

Afterwards I would like to get back to the discussion we started here: https://github.com/zowe/vscode-extension-for-zowe/issues/423 and some of the other ideas mentioned there such as the automation of profile creation from @jalel01. I would like to learn and discuss more around that.

[jelaplan]

@jellypuno WRT tokens, need to talk that over with Dan. I've started writing a response here but keep deleting it because my comments are likely not to bring clarity.

[jelaplan]

@phaumer How do you anticipate the user choosing between zOSMF and FTP as a connection method?

[dkelosky]

sorry @jellypuno - sometimes I miss these. I don't know if I fully understand the proposal - hopefully the token additions to the profile are transparent to the proposal, just an addition of extra fields in the profile.

[jelaplan]

I imagine the choice of FTP or z/OSMF being part of the quick pick. But for many users, especially z/OSMF capable users, it would be nice to not ask that question at all. One way to handle that would be to add a split button. If they click the + icon, they use zOSMF and proceed to setup a connection. If they click the right side arrow, they get a menu to choose between z/OSMF and FTP or additional choices.

Here is an example of a Bootstrap spilt button.

[JillieBeanSim]

I have been working on this in my fork here https://github.com/JillieBeanSim/vscode-extension-for-zowe/tree/work-with-updates
Here is a quick gif of creating a FTP profile dynamically using the schema that is retrieved by the CLIProfileManager:

[phaumer]

One compromise between the type drop-down and the question @jelaplan could be that we would only ask for the type if there is actually more than one profile type registered. So users without any extensions will not see a difference to what they see today.

(except for our proposal to get rid of the one question for a connection URL and split it into host and port as they current approach requires more typing; all those colons and slashes)

[jellypuno]

One compromise between the type drop-down and the question @jelaplan could be that we would only ask for the type if there is actually more than one profile type registered. So users without any extensions will not see a difference to what they see today.

I like this one. I think it's good to ask the type only if the plugin is installed.

(except for our proposal to get rid of the one question for a connection URL and split it into host and port as they current approach requires more typing; all those colons and slashes)

@MikeBauerCA @jelaplan Personally, I am also leaning on this split. It will also help when we add the basePath. Since we already have issue #579 , I think it would be better to just split it.

[jellypuno]

Just tagging #667 in case you're interested to include this feature as well.

[JillieBeanSim]

I'm wondering if all fields in the meta data will appear as questions in the quick pick? We may want to have some fields that are used in CLI but not appear in the Zowe Explorer quick pick.

@jelaplan As of right now all fields in meta data are appearing as questions in a textbox. The best way to get around this would be to rely on the required: true within the fields definition. This way only required fields are appearing as questions. Although just relying on that would leave out some important fields like reject-unauthorized and in zosmf port isn't a required field but has a default value.

So to solve that, keep with the questions that are there already implemented if they fall in the schema of alternate profile type, then after those are answered begin relying on required:true for additional questions from profile types other than zosmf.

[MikeBauerCA]

Thank you @JillieBeanSim for the contribution and providing a clear picture of the planned implementation!
Users tend to experience difficulty entering URLs. Some of this is due to our original lack of flexibility handling user input (e.g. #579). I am okay with separating host & port into separate questions but would defer to @jelaplan.
I agree with @phaumer that users without any extensions should not see any change from what they see today. But, for users that have extensions installed, I think a split button makes sense if this UI element is available. For now, the default main button would be for creating a z/OSMF profile. But maybe that could also be configurable in settings so that folks who only use FTP for example can benefit from this quicker route.
One UX concern I have (likely out of scope of this issue) is having folks proceed through a long sequence of configuration questions. For the short term, we need to ensure we are providing default values where possible with the ability to change them. We could even just accept the default and change later if needed. For example, users tend to not understand the reject-unauthorized prompt so we could just default to true to be secure and then if it is a problem prompt the user at that time to see if they would like to proceed with reject-unauthorized as false. I also think #667 will help some but we may also want to research better ways of asking for this much user input.

[phaumer]

@MikeBauerCA what do you think of a more file-based solution as outlined in https://github.com/zowe/vscode-extension-for-zowe/issues/423

[JillieBeanSim]

@MikeBauerCA with what I mentioned above with using the required:true for additional input questions along with using defaults if question is entered passed, this is how it will look:

• Zowe Explorer only with zosmf profile
  

• Zowe Explorer with FTP plugin
  

[MikeBauerCA]

@phaumer we would just need a way to allow users to enter username & password securely. But, I think editing a yaml is easier than navigating through a sequence of quick pick dialogs and aligns more with VS Code's design principles. It would be interesting to hear from our users on this though especially as some folks are coming to VS Code for the first time because of ZE.
Personally, I manage all my profile loadouts with the CLI + automation today and just add them to my ZE view when needed. I highly recommend this approach for projects. Anyone on the team can then pull the project, run an initialization task (that likely prompts for username, password, and perhaps host), and sets up all the profiles needed to work on the project. The other fields required for profile creation are simply maintained in some config file.

[MikeBauerCA]

@JillieBeanSim I'm not sure what was removed. But, anything we removed, if we encountered issues possibly due to the default setting, we should have a way to resolve that. For example, I noticed the timeout was removed from FTP profile creation so if a request timed out perhaps allow the user to change the setting at that time.

[jellypuno]

But, I think editing a yaml is easier than navigating through a sequence of quick pick dialogs and aligns more with VS Code's design principles.

I am not sure if this is a suggestion. If yes, this will be a problem with folks with SCS plugin.

[MikeBauerCA]

@jellypuno just an open discussion. Not a suggestion for this issue. If needed, we can continue the discussion on #423.

[jelaplan]

@JillieBeanSim Your idea about referring to the profile definition to decide which fields appear in the Quick Pick seems ok. The filed reject-unauthorized is very hard for users to understand so I'd rather we didn't ask that and instead handle it like in a browser that prompts for an insecure connection.
But, longer-term, I think of the APIML profile that will have a token field that can be populated after initial login. That field would never be prompted for in Quick Pick and always filled in by the system behind the scenes.

I captured the 'Profile Type' image from the animated GIF. I'd prefer the split button or some other mechanism because a lot of people just don't know how to answer this question. Another approach is showing separate icons that works ok if there is just zOSMF and FTP but not if there are more. I like Peter's suggestion to not ask if there is more than one profile type registered.

For the short term, we need to ensure we are providing default values where possible with the ability to change them.

In the quick pick, if we separate port, then auto-fill that with 443 so the user can just press enter.

[jellypuno]

@JillieBeanSim @jelaplan For the Profile Type, rather than z/OSMF can we just call it Default?

[phaumer]

Default is an ambiguous term. You mean default in relation to the bare bones install. But the end-user working with ftp or rse might want to set these other protocols as defaults for usage.

[JillieBeanSim]

@MikeBauerCA it's hard to know what field is a viable field of a dynamically gathered list of fields to ask the user for a value unless it is specifically stated within the schema ie. required:true or something to that extent. Otherwise we end up with a stream of questions where we ask about all fields listed.
If the default value gathered from the schema results in an issue ie. the FTP's requested timed out and needs to be updated, having issue #423 implemented and in place could remedy that easily.

@jelaplan I think auto-filling the textbox with default values is a great idea, and I can also look into using the split button for adding/creating profiles.

[jelaplan]

@jellypuno the term default is also overloaded because Zowe CLI has a concept of default profile which means that if you don't assign one as an option on the line, it uses that one.

I had considered adding a story to let a ZE user assign the default profile but after talking it over with Mike Bauer, we decided not to add fx that would be seldom used or used only by a small subset of users. There was a rationale that users who want to seamlessly move between CLI and ZE could benefit by setting the profile in the CLI, run a command, and then switch to ZE and start using it without having to do anything with profiles. Sort of an ambitious idea.

Here is how that default appears in listing profiles in the CLI
C02YN4D5JG5J:Zowe_CLI_Profiles jl661915$ zowe profiles list zosmf --sc
name: SR01x1 (default)
contents:
host: sr01brs.lvn.broadcom.net
port: 443
user: *
password: *
rejectUnauthorized: false