Object Permissions V2

This page describes the Object Permissions (Object Restrictions) system in SIWENOID v2. Object permissions control which datapoints, treatments (statuses), and commands specific users or user groups can access. They form the second layer of access control in SIWENOID v2, operating alongside user-level permissions.

Prev ← System Preferences and Engineering Options Next → License Upgrade

SIWENOID v2 uses a two-layer access control model:

• User permissions (configured in Users & Groups) — control which application functions and menu items a user can access. See User Permissions V2.
• Object permissions (configured here) — control which specific datapoints, treatments, and commands a user can see and interact with at the data level.

By default, all datapoints, treatments, and commands are accessible to all users. Object permissions use an opt-in restriction model: as soon as a datapoint, treatment, or command is added to any object restriction rule, it becomes visible and accessible only to the users or groups explicitly listed in that rule. Users not covered by the rule lose access to that object entirely.

Example — a three-role site:

• An engineer creates three restriction rules: one for full-access engineers, one for site supervisors, one for security operators.
• The security operator rule includes only the datapoints for their building and only the basic commands (Acknowledge, Reset). Engineering commands such as Exclude and Include are not added to the operator rule.
• Once those datapoints appear in any rule, they are no longer visible to users outside any rule. Ensure every user who needs access to a datapoint is covered by at least one rule before saving.

Important: Object restriction rules do not prevent the physical security system from generating events. Events are always received and logged by the SIWENOID server regardless of restrictions. Restricted users simply do not see those events in the client interface.

Exception — Alarm-category events cannot be hidden. Even if a treatment of Alarm category is included in a restriction rule, events of Alarm severity will always remain visible to all users regardless of their object restriction configuration. This is a deliberate safety measure to ensure that critical alerts are never suppressed at the operator level. Other treatment categories (Fault, Excluded, Supervisory, Informational, etc.) can be restricted normally.

Navigate to File → Options → Object Restrictions.

The Object Restrictions screen lists all currently defined restriction rules. Each rule is shown with its name and enabled/disabled status.

Click the Add button (plus icon), then select New restriction.

The rule editor opens. Configure the following fields:

Rule name
Enter a descriptive name that clearly identifies the purpose of this rule. Examples: “Ground floor operators — ground floor datapoints only”, “Guard team — no engineering commands”, “Tenant A — Building A datapoints only”.

Enable toggle
When enabled, the restriction is active and applies to the listed users and groups immediately. When disabled, the rule is saved but not enforced — all users can access the listed objects as if the rule did not exist. Use this to temporarily suspend a restriction without deleting its configuration.

Users and groups
Select the user accounts and/or user groups this restriction applies to. The restriction limits those users to the objects defined in the Objects tab. Users and groups not listed in the rule are unaffected by it.

After setting the rule name, users, and enable state, click the Objects tab to define which datapoints, treatments, and commands are covered by this rule.

The Objects tab contains three columns: Datapoints, Treatments, and Commands. Populate each column by dragging items from the Datapoint Hierarchy panel on the left.

Drag datapoints from the Datapoint Hierarchy tree into the Datapoints column. Each datapoint added here will be visible and accessible only to the users listed in this rule. Users not covered by the rule will not see these datapoints in the signal log, event log, or Datapoint Hierarchy screen.

Maps: If a restricted datapoint has an icon placed on a map, that icon will be completely invisible to restricted users — it does not appear greyed out, it is simply absent from the map view. Plan map layouts with this in mind: restricted users will see a map with no icons for the datapoints they cannot access.

Using logical containers for bulk assignment: Rather than dragging individual datapoints, drag an entire logical container node into the Datapoints column. This adds all datapoints within that container simultaneously. This is the recommended approach for restricting access by site area or building section — create a logical container representing the area first, then drag the container into the restriction rule. If datapoints are later added to that logical container, the restriction rule must be updated manually to include them.

Drag treatment (status) types into the Treatments column to restrict which event types the listed users can see. If a treatment is included in a restriction rule, users outside the rule will not see events of that treatment type in the signal log, even for datapoints they can otherwise access.

Use this to hide low-priority or operational statuses from operators who should focus only on actionable events — for example, restricting the Excluded treatment so that maintenance exclusions are visible only to engineers, not to security operators.

Note: Treatments of the Alarm category cannot be restricted. Even if an Alarm-category treatment is added to a rule's Treatments column, events of that type will remain visible to all users. This behaviour is by design and cannot be overridden.

Drag command types into the Commands column to restrict which commands the listed users can send. Users outside the rule will not see those commands in the command panel or in right-click context menus.

Common commands to consider restricting from operator-level users:

• Exclude / Include — removes a datapoint from active monitoring; should be reserved for authorised engineers.
• Force On / Force Off — overrides the physical state of an output; engineering use only.
• Reset — clears a latched alarm state; restrict if operators should only acknowledge, not reset.
• Acknowledge — typically left accessible to all operators.

After populating all three columns and verifying the user list and enable state, click Save. The rule takes effect immediately for all connected clients — no restart is required.

If a user belongs to multiple groups, and those groups have different object restriction rules, the user's effective access is the union of all their group rules. A user can access an object if any of their assigned groups grants access to it.

This means restrictions narrow access but multiple group memberships can restore it. If a user should be strictly limited, ensure they are not also a member of a broader-access group that would grant them visibility of restricted objects.

Before creating object restriction rules, plan the access structure for the site:

1. Identify the distinct user roles — for example: full-access engineer, site supervisor, security operator, tenant operator.
2. Define what each role should be able to see (datapoints by area or system) and what commands they are allowed to send.
3. Create logical containers that correspond to the access boundaries before creating restriction rules. This makes drag-and-drop population of the Objects tab faster and keeps the configuration maintainable as the system grows.
4. Map which treatments each role needs to see. Remember that Alarm-category treatments are always visible and cannot be restricted.
5. Remember the opt-in restriction model: adding a datapoint to any rule removes it from unrestricted access. Keep track of which datapoints should remain visible to all users (no rule needed) versus those that should be role-restricted.
6. After creating rules, test the configuration by logging in as a restricted user and verifying that only the intended datapoints, treatments, commands, and map icons are visible.

• Object restriction rules are stored in the SIWENOID v2 database and are included in database backups.
• Disabling a rule (via the enable toggle) suspends it without deleting it. This is useful during maintenance windows or reconfiguration.
• Object restrictions do not affect server-side logging. All events are always recorded in the database regardless of which users can see them in the client.
• If a logical container used in a restriction rule is restructured or renamed, verify that the rule still covers the intended datapoints.

Prev ← System Preferences and Engineering Options Next → License Upgrade