intersystems-community / vscode-objectscript

InterSystems ObjectScript extension for Visual Studio Code
https://docs.intersystems.com/components/csp/docbook/DocBook.UI.Page.cls?KEY=GVSCO
Other
108 stars 49 forks source link

Visually show Environment Status in VS Code #1359

Closed isc-egabhart closed 5 months ago

isc-egabhart commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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

isc-bsaviano commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

@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:

Screenshot 2024-05-10 at 9 36 32 AM

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 commented 6 months ago

@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 commented 6 months ago

@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 commented 6 months ago

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 commented 6 months ago

@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 commented 6 months ago

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

isc-bspead commented 6 months ago

@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 commented 6 months ago

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:

gjsjohnmurray commented 6 months ago

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

    "settings": {
        "workbench.colorCustomizations": {
            "commandCenter.background": "#ff0000"
        }
    }
gjsjohnmurray commented 6 months ago

For example:

image

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 commented 6 months ago

@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:

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 commented 5 months ago

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

isc-bspead commented 5 months ago

@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 commented 5 months ago

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 commented 5 months ago

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.