First Profile created using Che4z UI is not propagated to other views (e.g Jobs, USS)

[venkatzhub]

Scenario:

1. Create a new Che4z workspace
2. Click the + sign to create a new connection or profile in the Datasets view
3. Go thru the prompts to create the profile
4. The profile is created, but it shows up only under Datasets and NOT under Jobs or USS

As a user I expect it to show up in all three views - as this is the ONLY profile and hence should be the Default profile.

The behavior when the Default Profile created using CLI is different - that profile is 'loaded' into all three views.

The "Default" profile filter should be consistent between the UI and CLI path.

[phaumer]

It looks like that this was an explicit requirement so far as each addSession() method is called with the specific tree as a parameter. If we want to rather add the profile to all three then I could easily fix that as part of the cleanup I am doing in #377.

[venkatzhub]

I want the behavior to be consistent and predictable.

[phaumer]

If you assign me @zFernand0 then I can do it in one PR with #377.

[MikeBauerCA]

Thanks @phaumer! I assigned you and added the 1.1 release as the target milestone. Feel free to adjust to a later milestone if needed.

[MikeBauerCA]

I would recommend this behavior remain limited to the default profile. The first profile being added via the Explorer would be the default.

I think we should keep individual trees customizable as folks may not be using all three views for a particular connection. For example, they may not be interacting with USS on a particular system and therefore may not want that profile cluttering that USS tree view. I'll note that once a profile is added to a view, it is retained between sessions which is a nice feature for folks who are using multiple profiles.

[phaumer]

@MikeBauerCA thinking about this a bit more I agree actually; I fired off my response too quickly.
Also for the extensibility mechanism I am working on for #279 I assume that there are some profiles that only implement a subset of the three APIs, e.g. only USS or only MVS. I do not want to assume that a profile of a specific type implements always all three.

Therefore, my apologies, I would like to un-volunteer from this work and propose that this issue should be closed as Won't Fix.

[MikeBauerCA]

If profiles are created via the CLI, when using the Zowe Explorer for the first time, the default profile is automatically shown under each tree (otherwise the trees would only contain an empty Favorites directory).

@venkatzhub is requesting that if the first profile (and therefore default) is created via the Zowe Explorer then it is automatically shown under each tree so that the experience is similar. However, for folks just using the Zowe Explorer it may be odd that the first create adds to all three trees but additional creates only add to one tree. @venkatzhub what are your thoughts on this?

For folks using only the Zowe Explorer, there isn't really the concept of a default profile. To those users, the Zowe Explorer simply remembers which profiles were added to each tree. Default profiles are necessary for the CLI so that the profile does not need specified on each command. It was an easy integration with the Zowe Explorer to show the default profiles in each tree to help folks coming from the CLI get started.

[venkatzhub]

@MikeBauerCA - as a user I expect consistency. Conceptually, a user is creating a profile - either using CLI or using the UI, the fact that CLI needs a default profile is a detail that a user should not care. Yes, it is absolutely odd - and hence my request.

Either we should have the CLI default profile appear in the Datasets node, and let the user add it in for other views or have the first/default profile created using the UI show up in all the views like the CLI default profile.

[MikeBauerCA]

I'm in agreement with making the first profile created using the UI show up in all trees. I do think there are consistency issues here too but it is an improvement that may help folks get started.

A potential solution to the consistency issues is to provide an option to the end user to apply a profile to all trees. One means of doing this would be to add a + icon at the top level like this:

[zFernand0]

We may need to do some research on how to accomplish this "Global" ➕ icon on the "Header" of the extension.
I know there might be others that do this, however I have not seen an example where a multi-node extension provides actions on the header.
The only think similar to this is the Debug tab.

[MikeBauerCA]

Thanks @zFernand0. Definitely open to alternatives. Just some means of allowing the end user to apply a profile to all trees.

[jellypuno]

We have researched this before. And VSCode is not allowing that. The only way to add the plus sign in that "Global Container" it to have one tree. Like this:

One recommendation that we discussed is to have a Connection Details tree so you can do all your profile stuff there but this was put on hold because of tokens.

[venkatzhub]

@jellypuno : Connection details tree - can you please elaborate on that?

[jellypuno]

@venkatzhub I could. Basically what we initially thought of is to have a Connection Details Tree. In there you can add you're profiles and manage it (Edit, Delete etc.). That's it.

[jelaplan]

I'd be happy with the solution where it affects all three the first time.

If we wanted to offer the abilty to create a connection for one section or for all three, we could use a menu button. That would mean clicking on the + icon and open a menu that offers a choice.

[venkatzhub]

Would a simple solution be: As part of the UI or CLI - we have a mechanism (check box in UI, parm in CLI with default value true) that defaults to: Add this connection to all views? If the user doesn't want it - they can uncheck it or set the parm to false?

[zFernand0]

As long as we do not change the current behavior of first profile is the default on the CLI, I think the suggestion is ok.
I just wanted to bring that up since it could be considered a breaking change on the CLI (lts-incremental version) today.

[phaumer]

I think having a special behavior for the first profile is inconsistent though. Also automatically adding the default zosmf profile is something we should revisit. If we want to add support for all kinds of different profile types in the future such as ftp, zss, ssh etc then which one would you pick? Add all the default profiles? Also not all profiles will implement all the APIs for all three trees.

[venkatzhub]

Sorry, I should have been more explicit. The suggestion of adding a check box in UI or part in CLI would be for all cases - so the first one is not special. The user will have a choice of deciding what they want for every connection or profile they are creating.

Adding in other profiles is a separate discussion, I would like to understand the user scenarios associated with those, and hopefully design the UI based on those.

[MikeBauerCA]

After initial use, the profiles that have been added to each view are persisted between sessions. The decision to show the default z/OSMF profile on initial use was to help existing CLI users get started. If removed, the initial user experience becomes the same for all users where they must begin by adding a profile to each node.

[venkatzhub]

How do we close on this? Seems like we are going in circles.

[MikeBauerCA]

Please Vote!

❤️ -> Continue to automatically add the default profile to all trees on initial use. Add a means in the Zowe Explorer to add a profile to one or all applicable trees (re: #379 (comment)).
🎉 -> Do not automatically add the default profile to all trees.
🚀 -> Automatically add the first profile to all trees when it is created via the Zowe Explorer.
👍 -> No change.

If I overlooked an option, feel free to add.

[jelaplan]

Dana has stressed the need to have the extension get away from the CLI interaction paradigm of user request with system response. He stressed the need to follow conventional GUI type behaviors such as recognition over recall, ease of learnability, error prevention, and making information appear in a natural manner. In this case, for a brand new user, having the system automatically pull in a profile where one already exists will help in all these areas. It anticipates the user's action of creating a connection and does it for them.

[phaumer]

I agree, but should not try to reinvent Eclipse-type behavior such as complex dialogs and stick to how VS Code does things, as that was the recipe for success for them. The main difference I see is that it is mainly file driven, mostly free of buttons and dialogs. But it has explorers on the left as the main way of adding UIs.

I propose to add a proper Zowe CLI management explorer that would appear similarly to the NPM Scripts explorer in VS Code as a new tree view. It would show all the profiles available by type and would allow to add, remove update profiles. It could even be used to install and remove plugins. When editing it would just open the corresponding yaml file, the user you edit the yaml and saves it. Very simple. You can then drag the profile tree items into the other explorers or use the + to add them to one of the three explorer trees.

Role-model: Npm Explorer, always there even if package.json file is closed. A Zowe CLI explorer would always looks for profiles in the users home dir and always show them.

[venkatzhub]

@MikeBauerCA - how about an option that says let the user decide/choose (check bix in UI and parm in CLI).

Also, can we get the opinion of a real user, if we are voting?

[MikeBauerCA]

@venkatzhub I thought letting the user decide/choose was covered by option 1. From the Zowe Explorer, a user can decide to add a profile to one or all trees. Profiles that are added to trees are already persisted across sessions. Feel free to edit my comment with another option if needed. Everyone is welcome to weigh-in.

@phaumer perhaps the discussion of a CLI management facility could be the topic of another issue. Only trying to limit the scope of this issue.

[phaumer]

@MikeBauerCA agreed. I created #423.

[github-actions]

Thank you for raising this issue.
The community has 90 days to upvote 👍 the issue.
If it receives 10 upvotes, we will move it to our backlog. If not, we will close it.

[zFernand0]

It seems that this feature request could be implemented in two different ways.

1. By adding a setting in ZE: Add connection to all views. Default true

   have a mechanism (check box in UI, parm in CLI with default value true) that defaults to: Add this connection to all views? If the user doesn't want it - they can uncheck it or set the parm to false

2. Wait for VSCode to implement this feature:
   Add an explorer/title menu contribution point microsoft/vscode#108271

[JillieBeanSim]

This enhancement has had no community activity for 12 months. The issue also has less than 10 up-votes by the community. No action on this enhancement is targeted for the next 2 calendar quarters. Therefore, this enhancement is being closed. If you feel that this enhancement should continue to be available for community up-votes, you may reopen this issue.