Skip to content

Data Views Concept

What a data view is

A data view is a named, ordered list of rules over the tag namespace. Assign a view to a user and that user sees only the tags the rules allow.

Views are managed on the Data Views page, which is Administrator-only. The page describes them as "Named tag-scope rule sets. Assign a view to a user under Users & Access to narrow the OPC-UA data they see."

A view has an ID that never changes, an optional Name and Description, its rule list, and two switches: Read only and Audit writes.

Where a view applies

In this release a view scopes the OPC-UA address space this node serves. That covers what a client can browse, what it can subscribe to, and what it can write.

A view does not narrow this management console, and it does not narrow the node's management API. Those surfaces are governed by roles instead. Do not use a view as the only control over who can read a node's configuration.

Views are also per node. A view configured on one node scopes the sessions that connect to that node. It does not filter what a parent Flowgate node collects from it: a designated Flowgate peer reads its child through the chain and is never narrowed, because narrowing it would make the chain silently drop data rather than deny a person.

The rules

Each rule is a tag path, matched segment by segment against the / separated tag namespace.

Rule form Matches
plant/line1/temperature That exact tag.
plant/*/temperature One segment in that position, for example line1 or line2.
plant/line1/** Everything under plant/line1, at any depth.
!plant/line1/secret Excludes what it matches.

Put ! in front of any of the first three forms to turn it into an exclusion. In the rule editor the same thing is done by toggling a rule between include and exclude.

Partial wildcards are refused. A rule like temp* is rejected when you save the view, because the matcher has no partial wildcards and the rule would only ever match a tag containing a literal asterisk.

Quality selectors are refused inside a data view. Filtering on quality would make the address space appear and disappear as a tag's quality changed, so quality belongs on routes rather than on views.

Connector selectors do not narrow tags

A rule of the form @connector:<id> is accepted when you save a view, but it never matches an individual tag when the view is enforced, because the enforcement path matches on tag path only. Two consequences matter:

An exclusion such as !@connector:secrets hides nothing. A later include rule such as ** will still make those tags visible.

An include such as @connector:plant makes folders visible but no tags.

Write rules as tag paths. Do not rely on a connector selector to hide data.

Each node holds up to 64 views, and each view up to 256 rules.

How rules are evaluated

The rules are walked in order and the first rule that matches decides the tag. Order is therefore meaningful: an exclusion only wins over an include that comes after it.

If no rule matches a tag, the tag is hidden. There is no implicit "allow everything at the end".

Folders follow the tags. A folder stays visible when at least one allowed tag lies somewhere beneath it, so a user can always browse down to their own tags.

Check a rule set before you save it

The rule editor has a Test a tag path box. Type or select a tag path and the node evaluates it against the rule list you are currently editing, including unsaved changes, and highlights which rule decided it.

Assigning a view to a user

A view is attached to a user account, on Users & Access. It then follows that account into every OPC-UA session it opens.

  • A user with no view assigned sees all data, unless the node requires a view (see below).
  • A user with one or more views sees the union of them. A tag is visible if any assigned view allows it.
  • A user whose every assigned view is parked or no longer exists sees nothing. It never falls back to full visibility.
  • Administrators are exempt and always see everything. The exemption is per node, so an account that is an Administrator on one node and an Engineer on another is only exempt on the first.
  • Anonymous OPC-UA sessions are never narrowed by a view. Control anonymous access with the node's OPC-UA user authentication settings.

Making a view mandatory

Settings has a switch called Require a data view for tag access. When it is on, a user with no data view assigned has no access to any OPC-UA tag until an Administrator assigns them a view. Administrators are always exempt. The change applies live.

Assignment changes reach sessions that are already open. Narrowing a view degrades a running subscription within one sampling interval, with no reconnect needed.

What a scoped user experiences

A tag outside a user's view behaves, for that session, exactly as a tag that does not exist. Browse does not list it, and reading or writing it returns "unknown node id" rather than an access-denied error. This is deliberate: a distinguishable refusal would confirm that data exists outside the session's scope.

There is one deliberate exception. If a tag is visible but the view is Read only, a write is refused as access denied, because the session already knows the tag exists.

Read only and Audit writes

Read only makes a view contribute visibility and never write permission. A client is told the tag is read-only, so it does not offer the write in the first place. A user who holds only read-only views sees their scope and writes nothing.

Audit writes is on by default and has nothing to do with access. Turning it off excludes successful writes into the tags this view allows from the data audit chain, whoever makes them. Refused, failed, aborted and clamped writes are always recorded. The Data Views list marks such a view with an Audit writes OFF chip.

That exclusion only acts while the node's data-write auditing is running with a filtered scope, shown on the Audit Log's Audit settings tab. On a node recording every write, the switch changes nothing.

Separate manual and automated write sources

Audit writes are meant to record operator actions into the system. They are not designed to handle fully automated users such as a SCADA system. If there are many writes happening per second the audit log can be filled up with all of these operations. It is recommended to separate out manual users and automated users so that there is traceability for operator actions while not degrading performance.

Built-in views

Three views always exist and cannot be edited or deleted:

ID Name What it does
all-data All Data Sees every tag, read and write.
read-only-all-data Read Only - All Data Sees every tag, read-only.
no-access No Access Sees nothing: every tag is hidden.

Those three IDs are reserved. You cannot create a view of your own with one of those names.

A view can also be parked, which leaves it configured but out of force. The list marks a parked view with a Parked chip.