https://community.intersystems.com/post/how-recover-management-portal-s… is a place to start. 

Routines and classes created and edited in Studio are stored within the InterSystems database associated with the namespace Studio connected to. 

If you'd like to add your vote to getting InterSystems to publish on npm the package that adopters need, please consider doing that at https://ideas.intersystems.com/ideas/DPI-I-326

Previously raised at https://github.com/intersystems/language-server/issues/77 and in several other issues that were marked as duplicates of this.

Good to see this.

Minor nit is the Info panel at https://openexchange.intersystems.com/package/ObjectScript-Package-Mana… still has some links pointing to the old intersystems-community repo. They forward correctly but deserve to be updated anyway.

@Benjamin De Boe on WRC #956754 (2021.1) we reported that the InterSystems UDL export and load utilities ignore the /exportselectivity and /importselectivity qualifiers. We were told this is intentional and no changes were planned. Did this change? Are they now supported? If so, from which version onwards?

Probably our biggest pain point related to InterSystems software upgrade, and one we have to try and make sure sites using our Deltanji source code management tool are aware of, is that the procedure can result in class dictionaries of remote databases being upgraded to a dictionary version that the instance hosting the databases cannot handle.

Our Deltanji documentation now includes this paragraph in the section about InterSystems platform upgrades:

Before upgrading an InterSystems IRIS, Caché or Ensemble instance we strongly recommend that you first disable all ECP connections the instance makes to other instances. Leave these connections disabled until after you have completed the upgrade, including execution of any post-upgrade steps recommended by InterSystems such as the recompilation of code in all namespaces. These precautions should prevent the upgrading instance from inadvertently upgrading class dictionary entries and routines on remote instances which may still be running an earlier InterSystems platform version.

Good video. One tip I have is that at 4:18 it advises using a command to add second and subsequent folders to a multi-root workspace. Instead I recommend clicking on the InterSystems Tools icon in the Activity Bar, then using the Servers tree (contributed by the Server Manager extension) to find your server and namespace, then clicking the pencil button (Edit Code in Namespace). This adds an isfs entry to your workspace. The eye button alongside it will add an isfs-readonly entry instead.

Indeed you can do the whole of the workspace creation from that tree. With nothing open in VS Code (no folder, no workspace) click all the pencils or eyes you want. To name and save your workspace use "Save Workspace As..." from the File menu. If you haven't done that by the time you close the VS Code window you will be prompted to save or discard the as-yet-untitled workspace. So if you just wanted to browse a server speculatively you can use an untitled workspace and discard it when you exit.
 

How intriguing Rob.

May I suggest you edit the post and change the language at the top of the CodeSnippet elements so they're set to JavaScript instead of ObjectScript? Or if you prefer, ask me and I'll do it using my DC Moderator powers.

In the intersystems.servers object in your settings JSON you can add a pathPrefix property within the webServer object of your connection definition. In your example:

"intersystems.servers": {
...
    "server1": {
        "webServer": {
            "host": "localhost",
            "port": 443,
            "scheme": "https",
            "pathPrefix": "/instance1"
        }
    },
...
}

Interesting. Based on doc at https://docs.intersystems.com/healthconnectlatest/csp/documatic/%25CSP… the common attribute of all the faultily-displaying properties is that they are calculated. Does that hold true for the ones not shown in your screenshot?