Hi @Igor Barboza, this was changed for version 3.4.0 in PR #1681. You can view that and the linked issue for more detailed reasoning for the change, but in short we had reports of files being synced to the server automatically with incorrectly generated names. We decided that it would be preferable to avoid that at the cost of the user having to add the class name manually. The cursor will be automatically placed in the correct position in the document though.

A REST implementation method can do anything, including Dynamic SQL queries. Do you need to allow arbitrary SQL execution though? If all you need to expose is the data in one table with some filtering you can have an endpoint like GET /epic/master (path is arbitrary) and have query parameters for filtering. The implementation can use SQL to popular the results under the hood without needing the end user to write SQL.

I think in my ideal world, I would be able to make my own branch for my modifications, make changes, then commit them to the server when ready (thus deleting the branch). But if I want to be able to do that, I think we need to aim for a single-user environment, which means some sort of IRIS instance on my machine, or a dedicated environment just for my new branch on the server (as you suggested), although I don't quite understand how that would work.

This process is exactly what I was suggesting. Each developer gets their own IRIS, like they have their own copy of the code in the dedicated branch for the feature. Think of IRIS as the SDK, like the JDK for Java or Node.js for JavaScript. Your setup is complex, but if you have a process to set up your shared dev server then you can have the devs run that to set up their own servers. If developers won't be running tests that require the full setup, then the instance setup becomes even simpler. You can then have a CI/CD pipeline in your git provider that moves code to the shared test instance when it's committed to the main develop branch. With a setup like this, you can have as many devs working on as many projects as you like without them blocking each other. Any conflicts between changes will be resolved when the devs submit their code for a merge/pull request on your main branch.

Hi @Michael Derr, I recommend you have an isolated dev environment for each branch, whether that be a whole server or just a namespace. You can have Embedded Git configured to a different branch in each environment. Developers would then work in the environment that corresponds to the branch. This can be achieved with only server-side source control, but it also sets you up nicely to move to local source control in the future if that's a goal. 

Hi @Stephan Gertsobbe, there is no exact equivalent for exporting an entire Studio project in a single XML file. The command I mentioned is the closest approximation. The best workaround is to use a terminal to do the export. Since you mentioned using these exports for backup and that you have server-side source control in use, I would expect that your files being tracked in source control would constitute the backup. 

Source control support for projects files themselves is limited due to the way we edit them. The Atelier REST API used by VS Code has no support for Studio Projects since the concept didn't exist in Atelier. VS Code uses SQL to modify projects instead. This mechanism was chosen for its backwards compatibility since Studio Projects users tended to be on older server versions. Source control UserActions are fired for projects, but not all of the lifecycle hooks will because we are not using object access. 

Hi @Neil.Thaiss451, the inactivity timeout for the new applications is currently hard-coded and cannot be configured by users. We have received feedback that users would like to configure the timeout, so we are looking into the best way to expose that functionality for all our new apps. We hope to address this feedback in a future release. Thanks for trying out the new apps!

For anyone else who may be interested, here is my answer to @Ricardo.AlvesdosSantos's question that I provided on the GitHub Discussion he opened:

The extension intentionally doesn't support what you want to do. You have to pick a side. Since you're using Git and are happy to edit the files on your local file system, I suggest you turn off source control on the server and fully embrace the client-side editing workflow. Your local file system will be the "source of truth" and the extension will sync files with the server on save and compile them. The only change is that instead of using IRIS to run the source control actions, you can use any number of industry-standard Git-compatible tools. VS Code works well with Git out of the box, and there are additional extensions you can install to make that experience even better. You can also use a different GUI application like GitHub Desktop or Sourcetree, or the git CLI directly.

If you're expecting those keys to be defined in the first element of the "items" array like the example code, you can do this:

If responseData.items.%GetTypeOf(0) = "object" {
  Set pResponse.COMPortalURL = responseData.items.%Get(0).portalUrl
}

This assumes that "items" will always be present and be an array. It checks if the first element of "items" is a nested object, and then sets the target object property to the value of portalUrl in the nested "items" object. You don't need to check if portalUrl is defined since referencing an unassigned key in a %DynamicObject will return the empty string instead of <UNDEFINED>.