Importing XML files bypasses server side source control

[mcwebtree]

I have an iris server with Deltanji server side source control.

If I try to edit any files, the source control forces me to check out the files I wish to work on. This is as expected and desired.

If I import an XML file with changes from another location, VS Code allows the import and deploys the files to the server without any intervention from the source control. I can then open the files on the server in VSCode and see the changes to the files. This is NOT as expected or desired.

If I then go to modify the files further in VSCode, I'm forced to check out as expected.
The standard Deltanji actions then overwrite the imported changes with the source controlled version from the repository, (again expected and desired behaviour).

The issue is that the import of XML does not invoke any source control actions so invalidates the integrity of the source controlled environment, and because those imported changes are rolled back when a file is later edited could result in dangerous code regression errors which become very hard to trace.

[gjsjohnmurray]

Adding the observation that IRIS Studio's equivalent import feature does the right thing, consulting with source control about the status of the document it's about to overwrite, then skipping the ones that aren't currently checked out.

[isc-bsaviano]

@gjsjohnmurray What are we missing? This extension already triggers the ImportListOfDocuments UserAction (number 6).

[gjsjohnmurray]

After that UserAction completes I think you should still check the source control status of each item before you import it, skipping any that aren't checked out. I think that's what Studio does. After all, a source control class (SCC) might not implement user action 6 processing. And even if it does it might not be able to check out all of the documents that are about to be imported.

Implementing a test SCC that always reports every document as source controlled but not checked out, and that does nothing with UserAction 6 should reveal the difference between how Studio's import behaves and how VS Code's does.

[isc-bsaviano]

I just checked and Studio does call GetStatus() after action 6. I would think that the SCC would be smart enough to block the load in the OnBeforeSave() handler if the document isn't editable, but I will update the extension to replicate Studio's behavior.

[isc-bsaviano]

@mcwebtree You can use the VSIX in the zip file attached to this comment to test my fixes for your two issues.

vscode-objectscript-3.0.5-dev.1616.vsix.zip

[mcwebtree]

Hi
I have tested this release and it does not appear to fix this issue.
It does fix the export file location output.

// Export a file to test import.
Exporting to XML started on 07/18/2025 15:15:57
Exporting class: Audit.ClassMasterHistory
Export finished successfully.
Exported to c:\Users\mark\Downloads\test.xml

// Edited the XML to add a new property to the Class

Load started on 07/18/2025 15:17:28
Loading file c:\Users\mark\Downloads\test.xml as xml
Imported class: Audit.ClassMasterHistory
Load finished successfully.

Compilation started on 07/18/2025 15:17:33 with qualifiers 'cuk'
Compiling 2 classes
Compiling class Audit.ClassMaster
Compiling class Audit.ClassMasterHistory
Compiling table Audit.ClassMaster
Compiling table Audit.ClassMasterHistory
Rebuilding view Audit.vwCodeChanges
Compiling routine Audit.ClassMaster.1
Compiling routine Audit.ClassMasterHistory.1
Compilation finished successfully in 1.602s.

// Opened the file in VSCode

New property is visible.

// Deltanji Output

15:17:50 Status: Audit.ClassMasterHistory.cls not checked out at Programmes : Audit.ClassMasterHistory.CLS [F.0]

// Started to edit the file to edit the new property

// Forced to checkout as expected.

// New property is now missing.

[mcwebtree]

Line number changes are down to amended header in checked out file.

[isc-bsaviano]

@mcwebtree Can you turn on the objectscript.outputRESTTraffic setting and send me the output? I want to see what the result of the GetStatus(?) query was. I verified that this worked when the editable column was set to 0 by the source control class.

[gjsjohnmurray]

My testing with https://github.com/intersystems-community/vscode-objectscript/releases/tag/v3.0.5-beta.8 (the first beta with the fix) confirmed that @isc-bsaviano's change has resulted in the importing of an XML containing a class controlled by Deltanji but not checked out there to skip importing the class.

intersystems-community.vscode-objectscript version 3.0.5-beta.8 activating with proposed APIs available.
...
Skipping 'Testing.X12FileServiceRoutingRule.CLS' because it has been marked read-only by server-side source control.

The same test with beta.7 went ahead with the import, ignoring the Deltanji status of the class.

intersystems-community.vscode-objectscript version 3.0.5-beta.7 activating with proposed APIs available.
...
Load started on 07/18/2025 16:32:29
Loading file c:\s\junk.xml as xml
Imported class: Testing.X12FileServiceRoutingRule
Load finished successfully.

Connected to Deltanji as user JohnM in INTEROP on YAH

Compilation started on 07/18/2025 16:32:32 with qualifiers 'cuk'
Class Testing.X12FileServiceRoutingRule is up-to-date.
Compilation finished successfully in 0.015s.

@mcwebtree are you certain that the new VSIX got activated? Assuming you have enabled proposed APIs you should see its version string announced at the top of the ObjectScript output channel.

[isc-bsaviano]

@gjsjohnmurray Mark emailed me the REST traffic logs. The GetStatus() query returned no rows, so I think he imported the class in a namespace with no source control enabled.

[mcwebtree]

@mcwebtree are you certain that the new VSIX got activated? Assuming you have enabled proposed APIs you should see its version string announced at the top of the ObjectScript output channel.

@gjsjohnmurray This is the version I was testing on, which I took from the earlier comment.

intersystems-community.vscode-objectscript version 3.0.5-dev.1616 activating with proposed APIs available.