I agree, but unfortunately Portal's edit forms for config items always apply settings  into the production class (the XData block). Even worse, Portal ignores the source control status of the production class, so you can't prevent these changes. Portal users have to go elsewhere to add/edit System Defaults values. It's far from obvious, nor is it easy. And because they don't have to (i.e. the users can just make the edit in the Portal panel and save it) nobody does. We raised all this years ago, but so far it's remained unaddressed

See also https://community.intersystems.com/post/system-default-settings-versus-…

Folder within VSCode? Or folder on your local disk, that you could browse using Windows Explorer or macOS Finder in order to see a set of textfiles containing classes, routines etc?

Please clarify what you are referring to when you say "client-side code".

I've checked that it compile, is synchronized server-client and vice versa.

Is this referring to when you're using the Serenji extension? If so, understand that there is no client-side copy of your code (so no synchronization involved). Serenji works directly on your server-side code.

It's good. Only I'm missing the intellisense

Yes, Serenji doesn't yet do a good enough job of providing Intellisense. It's on our roadmap.

If you disable ObjectScript VSCode and enable Serenji I hope you'll be able to work the Serenji way. Please try it.

Did you intentionally start your Serenji service process on port 43221 rather than the default port, which is 43211?

You can check the status of that service process by running this command in a Cache Terminal:

D ^%Serenji

The output includes  a section like this:

Serenji explore/edit/debug service
----------------------------------
 Service status: Running
   Primary port: xxx
   Aux port min: xxx
   Aux port max: xxx
 Server address: xxx

@Douglas Foster if you're going to get the HALT info added to the Docker Hub page, maybe also clean up the debris I've highlighted below:

Be aware that if you're using InterSystems IRIS Community Edition you can't do this.

If you agree with me that InterSystems decision to disable the mapping features in Community Edition should be reversed, please go to https://github.com/intersystems-community/iris-community-edition/issues… and +1 this issue.

Also here. I beat you to it!

I notice that your mappings get code from ENSLIB

My use-case is a bit different.

Can you create a new database and namespace pair called XYZ and then define a %ALL mapping so that the globals ^XYZ and the routines XYZ* and the package XYZ get fetched from your XYZ namespace from all other namespaces, e.g. USER ?

I'd expect mappings to ENSLIB to work, otherwise the "Ensemble" features of IRIS would be broken in Community Edition.

It seems to me that those are allowed but mappings we define to our own databases get ignored.

I was able to create the mappings, but they don't seem to work for me. Not even after an IRIS restart.

I'm using the %ALL pseudo-namespace.

There's a section about Community Edition limitations in the document at https://irisdocs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Pag…

Here's a screenshot of what it currently says:

A big disappointment for me is the exclusion of namespace mapping. Those of us who create tools for the InterSystems world commonly use namespace mapping to make our tools available in the users' namespaces. See Evgeny's article here

Expanding on what Evgeny wrote, the new Serenji extension from us at George James Software gives you an experience that's most similar to what you're used to with InterSystems Studio. It connects you directly to the namespaces of your servers, even if they're running versions that are too old to support the Atelier REST APIs which other VSCode extensions depend on.

Plus, Serenji offers debugging.

To clarify Robert's answer, on InterSystems IRIS the database is called IRISLIB, and on Caché, Ensemble etc it is called CACHELIB.

But rather than having to reload your own non-%Z/%z routines after every upgrade you could create a dedicated database for those routines and then use %ALL-type mapping to make the routines available in all of your namespaces.

More info:

• https://community.intersystems.com/post/distributing-library-packages-p…
• https://community.intersystems.com/post/defining-global-routine-and-pac…

@oliver russell I think you are confusing the name of an InterSystems product (Caché) with the term 'cache'. Easy mistake to make, ever since InterSystems released Caché a couple of decades ago.

Right. And this is the reason why the tool with XYZ.Classes should be installed in XYZ namespace - in this way even if I map XYZ to %All all the data persistent data for XYZ.Classes will be stored in XYZ namespace, even if I use it from USER namespace, right?

This is only true if you explicitly add a global mapping of ^XYZ.* to the XYZ database (NB, mappings point to databases, not to namespaces). If you only mapped the XYZ package to XYZ, when an instance of persistent class of that package is saved from within the USER namespaces its data will get stored in the USER database.

Why do you think we need a prefix for globals? The matter to have a dedicated namespace/database for the tool frees us from this requirement, right?

If tool XYZ is installed in namespace+database XYZ and consists of classes in the XYZ package that's %ALL-mapped from XYZ, default storage for persistent classes in that package will use globals ^XYZ.* which will get stored in the default data database of whichever namespace the tool is used in (e.g. USER). These globals mustn't clash with globals created in the same place by a tool from a different supplier, or by the end-user's own apps.

If tool XYZ opts to consolidate user's data into the XYZ database, the natural way of doing this is with package mapping, in which case it's still necessary to avoid name collisions. There are ways the XYZ tool could use extended global references to route data into its private database, but this adds complexity.