NetXMS Forum

Description:
When attempting to localize/translate the NetXMS interface, I noticed that the items under the "Tools" menu for Infrastructure objects cannot be translated.

Upon further investigation, it appears these strings are hard-coded in the database under the `object_tools.tool_name` column, rather than being routed through the standard localization resource files.

NetXMS Version: 6.1.1
Operating System / Environment: Linux (Docker) [Server] / macOS [Client]

Steps to Reproduce:

1. Configure the NetXMS console/WebUI to use a translated language profile.
2. Navigate to the Infrastructure tree.
3. Select on a node or object and navigate to the Tools context menu.
4. Observe the language of the tool names.

Expected Behavior:
The names of the tools should support localization, either by mapping the database entries to localization keys or by allowing translations to be defined within the object tool configuration itself.

Actual Behavior:
The tool names are pulled directly from `object_tools.tool_name` in the database, bypassing the UI translation mechanism and forcing them to display in their original string format regardless of the user's language settings.

I would like to share some findings.

1. I managed to get the synchronization working at https://github.com/eduardomozart/netxms/tree/copilot/refactor-preferencestore-logic, but it synchronizes a series of preferences to the server, such as window size settings, which might not be the same when running NXMC on different computers. Also, some properties (like HTTP_* preferences for HTTP proxy settings on SWT) shouldn't be synced to the server and kept offline instead.

2. I started a second approach at https://github.com/eduardomozart/netxms/tree/copilot/refactor-preferencestoresync-logic aiming to synchronize only the `preferencepages`. However, some modules (like `networkmap`) don't seem to extend `PropertyPage` class, making it difficult to identify which preferences should be synced.

Currently, I'm thinking about creating a `PreferenceStoreServer` class and letting module developers choose which one to use. This way, using `PreferenceStore` saves locally (SWT) or in a cookie (RWT) as it is today, while using `PreferenceStoreServer` saves it as a custom user attribute.

Probably the solution is between those two. Using a secondary object would require merging both stores to make it usable with minimum impact to NXMC, as keeping different objects would make the PrefereceStore difficult to maintain and read. Maybe using the same PreferenceStore but first check if there’s a custom user attribute with the same name than preference and if there’s merge it with the PreferenceStore during startup and provide a way for modules to specify when saving a preference as a custom user attribute during save would be a better approach.

3. Another alternative would be to provide a Docker volume for the stateDir and map it to the netxms-web container. Actually, stateDir mounts to /tmp/jetty-<host>-<port>-<context>-<virtualhost>-<randomdigits>/state/nxmc.preference.<cookie_name_uuid>. Since the RWT preferencestore is kept there, user preferences are currently lost whenever the container is restarted.

Persisting this directory would bring other benefits as well, as I believe it also stores custom themes and important caches, such as 'Theme files', 'Map tile cache', and 'MIB file downloads'. The problem is even persistent this temp folder would be erased every time the .war file is updated.

4. Another alternative for the web client (RWT) would be using the browser's localStorage to save nxmc.preferences. Since the desktop client (SWT) simply stores its preferences in $HOME/.nxmc4—which is theoretically accessible by any other application running in the same user context—I assume this file doesn't contain highly sensitive data, making localStorage a perfectly viable and safe option. This would fix the nxmc.preferences persistence for RWT, but wouldn’t fix the issue that preferences aren’t synced per-user with the server.

1. Summary / Problem Statement

Currently, the NetXMS Management Console applies language, date, and time format settings globally across the entire system. While this works for single-site organizations, it creates a significant usability bottleneck in MSP environments and multinational companies. Having a single global locale forces operators in different countries—or clients accessing a multi-tenant environment—to adapt to a foreign language or an unfamiliar date/time format (e.g., MM/DD/YYYY vs. DD/MM/YYYY).

2. Use Case / Business Impact

• MSP Operations: A centralized NOC might be located in one country (e.g., Brazil, requiring pt-BR and DD/MM/YYYY), while tier-support teams or clients accessing the console are based in the US or Europe.
• Incident Response: When viewing alarms, events, or performance data for a specific Node or Device, misinterpreting the timestamp due to an unfamiliar global date format can lead to errors in SLA calculations or delayed incident resolutions.
• Client Portal: In a multi-tenant setup, clients logging into the console expect to see the interface in their native language and local time format.

3. Proposed Solution

Decouple the locale and time format settings from the global configuration and introduce a hierarchical preference system:

• User Level: Add options within the User Profile settings allowing individual users to override the global default and set their preferred Language, Timezone, and Date/Time format.
• System/Group/Tenant Level (Optional but ideal): Allow administrators to define default locale settings per User Group or Tenant, ensuring that when a new operator from a specific region is created, they automatically inherit the correct regional settings.

4. Expected Behavior

When a user logs into the Management Console, the system should render the UI language and format all timestamp fields (Alarms, Event Logs, DCI Data, Node properties) based on the specific settings attached to their user account, falling back to the global configuration only if no user-specific preference is defined.

5. Alternatives Considered

Currently, the only alternative is deploying separate NetXMS instances per region, which defeats the purpose of centralized monitoring and drastically increases administrative and infrastructure overhead.

Is your feature request related to a problem? Please describe.
Currently, installing and maintaining the NetXMS Management Console on Windows requires manually downloading the installer from the official website and running through the setup wizard. While this method works perfectly fine, it bypasses the modern package management ecosystem that many Windows administrators now rely on for seamless software deployment and automated workstation updates.

Describe the solution you would like
I would like to request official support for installing the NetXMS client console on Windows using Winget (Windows Package Manager). This could be achieved by submitting and maintaining a package manifest for the NetXMS Management Console in the official Microsoft community repository (https://github.com/microsoft/winget-pkgs).

This would allow Windows users to simply open their terminal and run `winget install NetXMS.Console` (or a similar identifier) to get the software up and running natively. It would also allow IT professionals to easily keep the management client updated alongside their other administrative tools using `winget upgrade`.

Describe alternatives you have considered
The current alternative is performing a manual installation using the executable from the NetXMS website or deploying it via custom enterprise scripts. However, having an official Winget package would greatly simplify the deployment and update processes, especially for users who use automated scripts to provision their IT management workstations.

Additional context
Since the NetXMS client console already has a Homebrew package available for macOS users (https://formulae.brew.sh/cask/netxms-console), adding Winget support would provide excellent parity for Windows users. It would significantly increase accessibility and make version management much easier across different operating systems. Thank you for considering this enhancement and for the great work on the project!

Hello Filip!
Thanks for the fast reply.
Here's the screenshot as requested:

My NetXMS user language is set to "English".

Hello Alex!
Thank you for your fast reply.
The documentation states that there is a specific MariaDB driver and the “netxms-dbdrv-mariadb” package for Debian: https://www.netxms.org/documentation/adminguide/installation.html#mariadb
So it didn’t exist on the Docker image, and I should use MySQL instead even after DB init? Because DB initialization still fails when using MariaDB as DBDriver on Docker, I think there's some issue where the code is not sharing the same code init template with MySQL for some reason.
Edit: My bad, the fix works as expected; there is a PR that improves the error handling at: https://github.com/netxms/docker/pull/3

I'm encountering a localization inconsistency in the NetXMS Web UI (Docker-based deployment).

Currently, even after explicitly selecting English in the user settings, several parts of the interface (menus and specific strings) continue to be displayed in Portuguese (Brazil), which is my browser's default locale.

It seems that the "Auto-Detect" logic—which is great as a default for new sessions—is still taking precedence over the manually selected language in the user profile.

The expected behavior should be:

1. Default: Auto-detect based on Browser Locale (Accept-Language header).
2. Override: If a user manually selects a language (e.g., English), this choice must take absolute priority, and no fallback to the browser locale should occur for any UI element.

What I've tried so far:

• Forcefully selecting "English" in settings.
• Logging off (user) and restarting the "netxms-web" container.
• Testing in Incognito mode (where it sometimes works, confirming the browser locale influence).

Environment:

• NetXMS Version: 6.1.1
• Platform: Docker / Web UI
• Client Browser: Chrome/Edge (Locale: pt-BR)

Thanks for your help!

I am deploying NetXMS via Docker using the official deployment-example/compose.yaml from netxms/docker (commit 55e823c), but replacing the built-in PostgreSQL container with an existing MariaDB instance.

During the database initialization phase, I encountered two related issues:

1. The server/files/dbinit.sh script has "pgsql" strictly hardcoded (nxdbmgr init pgsql), which forces PostgreSQL initialization regardless of the DBDriver configured in /etc/netxmsd.conf or environment variables.

2. If we manually override /dbinit.sh on init container to initialize MariaDB (nxdbmgr init mariadb), the process fails because nxdbmgr looks for a specific dbinit_mariadb.sql file in a directory that does not exist in the Docker image.

Environment:

• NetXMS Version: 6.1.1 (Build 6.1-452-gc20a8a4247)
• Deployment: Docker (using official deployment-example/compose.yaml)
• Database: MariaDB 10.11

Steps to Reproduce:

1. Setup the deployment using the example compose.yml file, pointing /etc/netxmsd.conf to a MariaDB database (DBDriver = mariadb.ddr).
2. Override /dbinit.sh (entrypoint) on init container via bind mount to execute nxdbmgr init mariadb.
3. Start the init container.

Error Log (when using mariadb driver for init):

NetXMS Database Manager Version 6.1.1 Build 6.1-452-gc20a8a4247
Initializing database...
ERROR: Cannot load SQL command file /usr/share/netxms/sql/dbinit_mariadb.sql
Database initialization failed
Unable to determine database syntax

Note: I verified inside the container that the directory /usr/share/netxms does not exist on the NetXMS Server Docker image.

If I change the /etc/netxmsd.conf  to use mysql instead (nxdbmgr init mysql), the database initializes perfectly, even though I am using a MariaDB container:

NetXMS Database Manager Version 6.1.1 Build 6.1-452-gc20a8a4247
Initializing database...
IMPORTANT: Generated admin password
   Login:    admin
   Password: PaSsWd
Please save this password - it will not be shown again.
You will be required to change it on first login.
Database initialized successfully

Suggested Fixes:

1. Dynamic Driver Selection: Update /dbinit.sh to dynamically read the database driver from a Docker environment variable (e.g., NETXMS_DB_DRIVER) or directly from /etc/netxmsd.conf, falling back to pgsql only if nothing is set. Changing nxdbmgr init pgsql to simply nxdbmgr init allows the utility to dynamically deduce the driver from /etc/netxmsd.conf, as intended by the documentation.
2. Template Mapping: Either include the dbinit_mariadb.sql template in the image build process or alias the mariadb initialization argument to use the mysql SQL template internally, since the schema structure is identical.

Hello,
I would like to contribute with NetXMS translation to PT-BR (Portuguese-Brazil).
The provided link is broken. How can I contribute? There's some GitHub repo?