Visually show Environment Status in VS Code

[isc-egabhart]

trafficstars

When connecting to a production environment it would be useful to have a visual indicator to prevent unintended changes. The environment information necessary is stored in ^%SYS("SystemMode"). For reference in Studio a production environment will display the document editing window in red.

[isc-bsaviano]

Changing editor colors could run into accessibility concerns, and configuring colors dynamically like this isn't that easy. I will look for a good place in the UI for this information.

[isc-solon]

https://marketplace.visualstudio.com/items?itemName=johnpapa.vscode-peacock ?

[isc-bsaviano]

It looks like that extension helps you configure workspace-specific colors. I don't think it does what this request wants, which is change the color based on some external environment info.

[isc-solon]

I added the Peacock link to suggest 1) "maybe this sort of colorization would work instead of what Studio does," and 2) "maybe it doesn't have to be an InterSystems extension that provides this functionality."

[isc-bsaviano]

@isc-egabhart I did some research into where in the UI I could show this information and I don't think there's a great place for this. The best I could come up with is the server connection status bar item. I could change the color to error (red) or warning (yellow) depending on the SystemMode, and show the mode in the tooltip:

However, I don't love this approach for two reasons:

1. This doesn't seem to be "in your face" enough to be worth the effort.
2. Users may think this symbolizes a connection error rather than a warning about the SystemMode.

[isc-bspead]

@isc-bsaviano - can you extent the text shown in this case? E.g. make it Red but also show it as "iris[USER] - Live System" to match the SMP verbiage? That will both make it more visible, and will make it more clear why it is Red.

Another option would be is there a console display which can show a warning and the System Status upon connection to that Namespace? (we would do this in Studio as well in the Output window).

I do think that this (especially the red visual) is better than nothing, and additional text should help to avoid confusion

[isc-bsaviano]

@isc-bspead I could add "Live/Test System" to the status bar, but space is at a premium there so it may interfere with other extensions/get hidden if the bar gets full. Adding a message to the Output channel on extension load or adding a new server-side workspace folder would be easier to do. Would that be enough of a warning?

[isc-bspead]

I think it is fine if it gets hidden if the bar gets full - I assume the hovertext of that piece of the bar would also say this?

Can you change the coloration of the text, or background of what you sent to the Output channel to draw a little more attention to it in the case of LIVE? Better yet, is Scrolling Marquee an option? ;) (j/k)

If we all of the above, that should help to lower the risk for all users that take advantage of the SystemMode feature in IRIS

[isc-bsaviano]

@isc-bspead I think the Output channel message might be the better place for this. I can show the Output channel so the message is visible, and can try to make the message red so it stands out. Which SystemModes need warnings, and should they all be red?

[gjsjohnmurray]

When using ISFS to connect to a Live system the ultimate protection is to make it a readonly connection.

[isc-bspead]

@gjsjohnmurray - true, but that isn't possible in all circumstances doe to the occasional need for 'break the glass' emergency debug code. Is there an option to default to Readonly but prompt the user about the need for edit access? @isc-bsaviano - if you play with settings in the SMP Memory Configuration page you can see the possible values of the global. I recommend Red is reserved for LIVE, and orange/yellow reserved for non-Dev and non-LIVE. Dev should be no special color, but the message can specify that they are connecting to an instance configured for Development

[gjsjohnmurray]

Is there an option to default to Readonly but prompt the user about the need for edit access?

Editing the xxx.code-workspace file and changing from isfs-readonly:// to isfs:// might suffice as a hack.

Other ideas:

• Set window.title at workspace level.
• Leverage profiles, and have a different color theme for your 'Live' profile. Then associate your live workspaces with that profile.
• Use server-side source control.

[gjsjohnmurray]

Apply color customizations in xxx.code-workspace file, for example:

	"settings": {
		"workbench.colorCustomizations": {
			"commandCenter.background": "#ff0000"
		}
	}

[gjsjohnmurray]

For example:

Server Manager could probably add these settings to the workspace it creates if it were to perform a server-side check of system mode when you pick the first namespace.

[isc-bspead]

@gjsjohnmurray - thank you for engaging with us in the brainstorming for this :) A little bit more background (which Brett has from discussions with my team yesterday) may be helpful:

• we do use server-side source control hooks! (visual cues as to the environment purpose is just another layer of protection)
• our change control system catalogs all of our environments, and we allow developers do download connection details to make it easy to engage with an app for the first time
• with Studio we autogenerated the Windows Registry keys to put the server in the Server Manager, AND to add Studio coloring to the status bar and document backgrounds to indicate LIVE (red) or TEST/UAT (yellow)
• with VSCode, we autogenerate a workspace definition file to provide access to all servers and Namespaces associated with that application (BASE/TEST/LIVE environments)

In our discussion with Brett, he thought he could just key off of the SystemMode global in order to provide auto-styling in VSCode to make it clear to the user what the SystemMode is .. this is what the above brainstorming is all about. It would be ideal if there are visual markers that the ObjectScript plug-in could automatically create so everyone can benefit.

If we're going to need to insert things into our autogenerated workspace definitions, then we need to have the visual indicators differ between when someone is looking at things in BASE, vs TEST, vs LIVE (since all 3 are included in the workspace auto-generated for easy developer access to the application Environments). The way the the customization settings appear to apply to the entire workspace, I don't know if this is possible.

[isc-bsaviano]

@isc-bspead Please see PR #1361 for my proposed implementation of this feature request.

[isc-bspead]

@isc-bsaviano - that looks great, thank you!! @gjsjohnmurray - if you have any brainstorms of additional things that we can add to our autogenerated workspace definition to impact coloring for a specific Namespace connection, I would love to hear about it as we would love to layer that as an additional protection on top of what Brett is implementing for automatic SystemMode detection (which is GREAT, btw :) )

[isc-bsaviano]

You're welcome @isc-bspead! I don't think there's a good way to do what you are asking (folder-specific settings inside a multi-root workspace file). It would be great if VS Code allowed you to put the settings into the folder definition. Maybe they'd consider that if someone opened an issue.

[gjsjohnmurray]

Folder-specific settings can already be supplied by the server once it has been prepped. Either follow these manual steps or install my Open Exchange package.

Note though that workbench.colorCustomizations cannot be set per-folder.