NetXMS Support Forum

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.

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.

Filed as https://github.com/netxms/netxms/issues/3480 for design discussion.

Option 3 is the right shape, but one thing needs settling before you build on it: user custom attributes will not work as a backing store for ordinary users. CMD_UPDATE_USER is handled by ClientSession::updateUser() and requires SYSTEM_ACCESS_MANAGE_USERS, with no exemption for modifying your own account — password change and 2FA binding both special-case userId == m_userId, custom attributes do not. A non-admin operator saving their own date format gets access denied.

So the per-user store needs a server-side change either way: a self-update path restricted to own custom attributes, or a separate per-user key/value store with its own command and access check. That choice determines the client API, so it should come before more work on the merge logic.

Beyond that, option 3 needs an explicit rule for which preferences are machine-local and which are per-user. Without one, every preference added later is a judgement call and the split rots — your HTTP_* and window geometry cases are exactly what such a rule has to answer.

Your points 3 and 4 are a separate problem, worth splitting off: the RWT store sits in the servlet container state directory, so it is lost on container restart and on .war update. Persisting that directory, or moving the store out of it, fixes preference loss in the web client on its own, with none of the per-user work — and it covers theme files, map tile cache and MIB downloads at the same time.