Direct use by the VS Code / Windsurf etc "vibe coding" features of resources with `isfs://` type URIs (i.e. server-side classes etc living only in an IRIS namespace) seems to be blocked by https://github.com/microsoft/vscode/issues/277970
Re the AD lockout caused by saved passwords, I assume this was after you had changed your AD password. After doing that did you use the Accounts button at the bottom of the VS Code Activity Bar to sign out the connections that used this AD account, and opt to delete the saved password for each?
When you launch VS Code I wonder if what's happening is that it's reopening whichever workspace was open at the time you last exited VS Code. To test this theory please use the "Close Workspace" option from the File menu before you exit from VS Code. Then the next time you launch VS Code do you still get the sign-in permission request?
Also, are you editing server-side (i.e. the old Studio paradigm), or client-side? And is your desktop Windows or macOS or a Linux variant?
You may be able to avoid having to install anything on the server by using the /action/query endpoint of the /api/atelier API to run a SQL query such as this:
SELECT
p.Name ASProject,
p.Description,
pi.Name AS Component,
pi.Type
FROM
%Studio.Project AS p,
%Studio.ProjectItem ASpiWHERE
p.Name = pi.Project
ORDERBYProject,
ComponentAre you using http or https?
You might find VS Code Profiles useful.
as before CSP and SMP
I am confused. The original post says:
No Management Portal or Web Services
The entire CSP/web stack is removed.
I received this message on Discord from one of the InterSystems team:
Demo cloud service doesn’t work for now, we disabled this feature. But you still can provide demo on your own server.
This text needs correcting, and not just because of the inconsistency about how many points an online demo is worth:
.png)
In your example does IE.cls represent your interop production class? One of the longstanding source control challenges of the InterSystems interop architecture has been the monolithic nature of the prodclass. Deltanji transformed the scene a few years ago by implementing source control at the level of the individual business hosts within the prodclass.
Unless your project and my project overlap on one or more business hosts, we can work alongside each other in a shared development namespace and each promote our work to test (and ultimately to prod) independently.
I'd like to set up an online demo of my entry, gj :: dataLoader, using the template suggested above. Yesterday I posted on Discord to request the service key as advised at https://github.com/intersystems-community/iris-google-run-deploy-templa…, but no reply yet. I assume it'll come either by DM on Discord (or here on DC), or else by email.
Since you are using a custom login class maybe the warning at https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cl… is relevant:
Usually, the login page is loaded before the user has logged in to InterSystems IRIS, so the requesting process runs under the CSPSystem user (or whatever user connects the CSP Gateway to InterSystems IRIS). As a result, the CSPSystem user must have sufficient privileges to load and run the code in the login page, which generally requires READ permissions on the resource protecting the database in which the login page is located.
So, a bit confusing that Open Exchange sent out an email just now saying that the voting is open, and closes on 7th December...
Maybe a consequence of Thursday being the US Thanksgiving holiday.
Many thanks for this. I have now published a new release of the gj :: configExplorer extension that works in VS Code on Windows.
I'm pleased to announce that InterSystems fixed the issue preventing this extension from working in VS Code on Windows. A new Windows-compatible release of the extension (0.0.4) is now available on Marketplace.
@Stefan Wittmann - Please expedite publication of version 2.0.3 of the Node.js package, which WRC tells me will fix the problem that's been causing my gj :: configExplorer extension to crash VS Code.
For the record, this was resolved at https://community.intersystems.com/post/vs-code-find-routines
Having read the "lively" thread discussion as it has developed so far, my suggestion is that the form should ask the poster if the report can be made public. If yes, then after it has been reviewed (by ISC staff? DC moderators?) for security implications it can be made public if there are none.
Did you restart VS Code after editing argv.json?
Have you followed all the steps documented in the README to enable Proposed APIs?
@Dmitry Maslennikov do you intend to address any of the 5 open issues on the iTerm repo, one of which is IMO a significant security vulnerability I reported more than a year ago?
Looks similar to at least part of the issue I covered in https://community.intersystems.com/post/webterminal-broken-iris-20242
Or use the tip at https://community.intersystems.com/post/visualize-your-intersystems-ser… from @Thomas Wuppermann
As noted in the original post, when a Windows version of the VSIX is built and used it crashes VS Code's extension host process. I have a WRC open for this, as I suspect there's a problem with how the Windows variant of the InterSystems API package has been built.
Meanwhile maybe try the steps in https://community.intersystems.com/post/how-windows-users-can-try-gj-co…
Ah, so I assume you reverse engineered the unpublished TCP protocol that the published Native API packages use, right?
I am curious to know which of the published and supported IRIS Native APIs this (the go-irisnative package) leverages.
gj :: configExplorer uses an IRIS Docker container for its test / demo workspace. Please see https://github.com/gjsjohnmurray/gjConfigExplorer/tree/main/test
The same for the idea I linked gj :: configExplorer to. Still "Needs Review" and no bonus awarded yet. 🤞
gj :: configExplorer now has 2 DC articles. I also claim the Find a Bug bonus for https://github.com/intersystems-community/nodejs-bugreports/issues/1