V{environment} always returns 'Server'— no longer distinguishes between WebClient and AndroidClient

Support - Assistance technique
,
1

Hi everyone,

I’ve been working with program rules and noticed that V{environment} no longer behaves as expected in version 2.42.3.1.

What I’m experiencing:
Regardless of whether I access the form through the Capture App (web) or the DHIS2 Android app, V{environment} always returns Server. It never returns WebClient or AndroidClient.

I confirmed this by creating a simple program rule with:

  • Condition: true
  • Action: SHOW WARNING
  • Message: V{environment}

Both on web and Android, the warning displays Server.

Expected behavior:
According to the documentation, V{environment} should return WebClient when accessed from a browser and AndroidClient when accessed from the Android app.

Is this an intentional change in 2.42.3.1 related to the unified rule engine? If so, is there an alternative way to differentiate between web and Android clients within program rules?

Thanks in advance!

1 Like
2

Hi @henry_lopez,

I’ve observed the same behavior in recent versions of DHIS2 where V{environment} always returns “Server”, likely due to server-side evaluation with the unified rule engine.

Since this removes the ability to distinguish between Web and Android clients, here is a workaround process that can help:

Proposed workaround (step-by-step):

  1. Create a custom data element or attribute
  • Example: entry_source
  1. Define possible values
  • “web”
  • “android”
  1. Populate this field depending on the context
  • On Android: set a default value (e.g. “android”)
  • On Web: leave empty or set “web” manually or via configuration
  1. Update your program rules
  • Replace V{environment} with conditions based on entry_source
  1. Test in both environments
  • Confirm that rules behave correctly in Capture (web) and Android

This approach avoids relying on V{environment} and restores environment-specific logic in a controlled way.

It would still be great to get confirmation from the team on whether this change is intentional and if an official alternative is planned. :eyes:

Thanks!

1 Like
3

Thank you @Henry_Lopez for getting this into our attention… I have triaged the issue to the team. :folded_hands:

Thanks!

4

Hi again @Henry_Lopez

This variable was experimental and doesn’t seem to be maintained and will probably not be supported as there is no strong reason to. Which is why it will help to understand your use case and see what’s the official way to handle it.

Would you kindly share more about the use case and how this is necessary for your use case?

Thank you!

1 Like