Channel Restrictions

Channel Restrictions

Every role grants access to either all channels or an explicit whitelist. A restricted user sees and touches only the channels on their role's list. Everything else is filtered out server-side before the response leaves the engine.

All Channels vs Specific Channels

The Channel Restrictions tab of the role editor offers two modes:

• All Channels - the role places no channel limits. Users see every channel their permissions allow.
• Specific Channels - the role carries a whitelist. Pick channels from a checkbox list, each labeled with its name and id.

Restrictions narrow scope, they never grant anything. A user still needs the relevant permissions (view channels, view messages, start/stop channels, and so on). The whitelist decides which channels those permissions apply to.

Two cases sit outside the whitelist model. Users on the admin role are never channel-restricted, and the editor disables the admin role's channel controls to match. A user with no role at all is denied every channel.

What Restriction Means in Practice

The plugin hands the engine a per-request channel filter through the engine's ChannelAuthorizer hook. The engine's REST layer then redacts channel-scoped data before returning or acting on it:

• Channel list - the Channels view lists only whitelisted channels, and channel summaries, enable/disable, and initial-state changes are trimmed the same way
• Dashboard - status listings show only whitelisted channels; start, stop, pause, resume, and halt requests are reduced to the whitelist before they run
• Messages - message browsing, content, counts, and reprocessing are checked against the channel id on every call; a request for a channel outside the whitelist is rejected with a 403
• Deploy and undeploy - deploy operations are scoped to the whitelist as well

The filter runs inside the engine's REST layer, so it applies no matter which client makes the call.

Deleted Channels

When a whitelisted channel is deleted, the role keeps the reference. The role editor lists these at the top of the Channel Restrictions tab under "Deleted channels (no longer exist)", each with a Purge checkbox.

Keeping the reference is deliberate. Channel ids survive export and re-import, so if the channel comes back the restriction picks it up again with no editing. Check Purge next to a reference and apply to drop it for good.

The Empty-Whitelist Guard

An empty whitelist means unrestricted, the same as All Channels. Switching a role to Specific Channels without checking any channels therefore does not lock anyone out. It opens the role to every channel. The editor warns before saving that state:

This role will no longer be restricted to specific channels. Users with this role will be able to access ALL channels.

The same warning fires if you purge a role's last remaining deleted-channel references with no live channels checked.

Limitations

Channel scoping is only as complete as the engine's redaction coverage. The plugin's permission checks have no channel dimension of their own; the whitelist is enforced entirely through the engine's ChannelAuthorizer machinery. A few engine endpoints do not pass through that machinery, so a restricted user who also holds the matching permission can still reach data across the channel boundary:

• updateChannel authorizes the channel id in the URL path but persists the channel in the request body
• getAllStatistics returns statistics for all channels
• getChannelGroups returns group-to-member references
• getServerConfiguration returns full channel and alert definitions (requires the backup permission)
• Alert create, read, update, and delete have no channel dimension

These are engine limitations, and the plugin cannot patch them. In practice the exposure is bounded by permissions: each of these endpoints still requires its own grant. Keep restricted roles lean, and avoid pairing a channel whitelist with broad grants like channel management or configuration backup where the boundary matters.

---

Home