Permissions Management

CORE RULES

• All access is denied by default. You must explicitly grant Allow.
• Every rule has three parts: Object (what), Subject (who: user or group), Relation (Allow / Deny).
• Reporting has two independent permission layers: Component (permissions/assign) and Data (permissions/data-assign). Both must be configured.
• Trading has one permission tree, TradingPxmApp (permissions/tradingApp-assign), covering trading connectors, their streams and accounts, and Trading Portal components.
• Monitoring has no permission settings here: access to the Monitoring Portal is granted in the Users component.
• Permissions are inherited: a rule on a parent object applies to all its children automatically.

Priority & Override Rules

Deny beats Allow at the same level. But a direct user Allow always overrides a group Deny.

What Each Object Controls

Component Permissions (permissions/assign)

Granting access to at least one field enables: dashboards, template creation/editing, and filters.
Granting access at the Reports top level = access to all report types and fields under it.

Data Permissions (permissions/data-assign)

Granting access to a Connector = access to all Connector Accounts within it.

Trading Permissions (permissions/tradingApp-assign)

A source in the Trading Portal combines a connector, a price stream, and a trading account: the user needs access to all three.
Without access to any component, the Trading Portal shows no components to add.

RECOMMENDATIONS

How Data Permissions Affect Reports

A report type that uses several data sources is listed in each of their rows: without access to any of them, the report is empty.

Common Mistakes to Avoid

1. Broad top-level Allow — Granting Reports or Data Filters at the root level gives access to everything under it, including items added in the future. Grant specific items instead.

2. AB Book for all users — Only grant AB Book access when the user role genuinely requires the global filter. It is a sensitive operational filter.

3. Connector vs Connector Account — Allowing a Connector grants access to all its Connector Accounts. If a user should see only one account, allow that Connector Account specifically.

4. User-level Deny is permanent — A Deny rule on a specific user cannot be overridden by any group rule. Use it deliberately.

5. Deleting a group in use — You cannot delete a group that is referenced in any rule. Remove all related rules in permissions assign / permissions data-assign first.

6. Component access without Data access — A user may have report types and fields allowed (Component), but if no data sources are allowed (Data), all reports that use data sources will be empty (see How Data Permissions Affect Reports).

7. Data access without Component access — A user may have data sources allowed, but without field-level Component access, the user cannot interact with any reports.

8. Trading: broad TradingPxmApp Allow — Allowing the top-level TradingPxmApp gives access to every trading connector, stream, account, and component, including those added later. For client traders, allow specific connectors, accounts, and components instead.

9. Trading: Connector vs Account — Allowing a trading connector grants all its streams and accounts. If a trader should use only one account, allow that account (and the stream it trades on) specifically.

10. Trading: accounts without components — A trader may have connectors and accounts allowed, but without at least one component (for example Trade Panel or Trading Desk) the Trading Portal has nothing to show.

Prefer Group-Based Rules

• Assign permissions to User Groups, not individual users whenever possible.
• Use object groups (Report Type Groups, Field Groups, Provider Groups, etc.) to manage related items together.
• For Trading, use Trading Connector, Stream, Account, and Component Groups — for example, one group per client segment — and assign them to user groups.
• This reduces configuration errors and makes future changes easier.