I came up with a better technique for using Yuzinji and Structure101g Studio to reveal which deprecated classes an app's codebase uses. Here's a screenshot showing the results for the Web Terminal 4.9.6 package on IRIS 2024.1

I adapted the tagging technique to identify the use of deprecated methods in non-deprecated classes. In the case of the Web Terminal codebase, no such usage was found.

If anyone reading this is interested in trying this on your own codebase please contact me through DC's DM facility, or email info@georgejames.com

Maybe related to https://community.intersystems.com/post/installed-iris-health-unable-cre...

Here's one way to verify from VS Code (but independent of the InterSystems ObjectScript extension) that the /api/atelier REST APIs are available on that server.

1. Start a new VS Code window (no workspace open)
2. In Extensions view, use the filter @id:humao.rest-client to find and install the REST Client extension.
3. From the File menu create a New Text Document, setting its language to http.
4. Paste this content:

GET http://localhost/api/atelier/v1/%25SYS HTTP/1.1
Authorization: Basic _system:SYS

Now click on the "Send Request" codelens that appears above the first line.

Maybe the trace facility on the Web Gateway Management page will yield clues. 

I'm guessing you need to add a `pathPrefix` property. See https://docs.intersystems.com/components/csp/docbook/DocBook.UI.Page.cls...

When you access IRIS Portal in your browser what is the url? 

TIP: if you are in a hurry, use the YouTube option to play this at 2x speed and you'll get through it in half the time.

It is often the case with large applications that developers would like to or need to work on unrelated parts of an application simultaneously. It is a limitation of the Git for Shared Development Environments application from the InterSystems Open Exchange that you cannot do this in a single namespace. That's because it is built on git, where you can only have a single branch checked out to a working folder at any one time.

Our InterSystems-native source control and integrated deployment solution Deltanji allows developers to create multiple separate branches within the same namespace.  Because Deltanji has finer granularity it can handle concurrent non-overlapping sets of changes in a single namespace, enabling users to check code entities out onto separate Change Requests, then promote these independently.

Even with a team as small as one person it is common for Deltanji-controlled development to take place this way. Use of QA and/or Staging environments ensures that unforeseen dependencies created in the Development environment between supposedly independent Change Requests will be detected before they can impact the Production environment.
 

Release notes indicate this feature landed in 2023.3

At some point since I posted the comment linked to above the rules got even more complicated. See https://docs.intersystems.com/iris20241/csp/docbook/DocBook.UI.Page.cls?... from the 2024.1 doc which states that "Some system default settings can override the corresponding production ... values" (my bolding).

That doc section names two settings but doesn't claim to be a comprehensive list 😾

Please also see https://community.intersystems.com/post/system-default-settings-versus-p... to try and understand how easy it is for a system-specific setting to get overridden by a setting added to the XData block of the prodclass. Then, if you're not super-careful about how you transfer the prodclass between environments you can inadvertently end up with the live production talking to the test interfaces.

This will need a server-side change as well as one in the VS Code extension. More info at https://github.com/intersystems-community/vscode-objectscript/issues/1375