Access Control Model

Access Control Model

Ideation uses a role-based access control system. This document explains how roles, permissions, and grants work together to determine what each user can do.

Roles and Permissions

Every access grant assigns a role to a user or group. Each role maps to a set of
permissions:

• Admin: Complete control over the object, including the ability to share it with
  others and delete it.
• Editor: Can create, view, and modify data, but cannot delete objects or manage who else
  has access.
• Viewer: Read-only access.
• Deny Access: Explicitly blocks all access. Used to override a project group's default role on a specific object (see Per-Object Role Overrides below).

Securable Objects

The following object types can have access control:

Two Ways to Grant Access

Access can be granted through two independent channels:

1. Project Group Membership

Every project has three groups, each with a default role:

When a user is added to a project group, they receive that group's role on the project and all objects within it (datasets, SAR reports).

A user can only belong to one project group at a time.

2. Direct Access (Per-Object Grants)

A user can be granted a specific role on an individual dataset or SAR report, independent of their project group membership. This is useful for:

• Sharing a dataset from a personal project.
• Giving a colleague outside the project access to one specific object.
• Granting a higher (or lower) role than the user's group-derived role on a specific object.

How Permissions Are Resolved

When a user tries to perform an action on an object, Ideation resolves their effective permissions as follows:

1. Is the user a project Owner?
   → YES: Admin on everything in the project (no override possible)
2. Does the user have a direct access grant on this specific object?
   → YES: Use the direct grant's role (overrides group role)
3. Is the user a member of a project group?
   → YES: Use the group's role (either default or per-object override)
4. Is the project public and the user is authenticated?
   → YES: Visitor role (Viewer by default)
5. None of the above → Access denied

Key Rules

• Owners always win: Project Owners have Admin access on every object in the project. This cannot be overridden, even by a direct Deny Access grant.
• Direct grants override group roles: If a user is a project Member (Editor) but has been
  granted Viewer on a specific dataset, they see that dataset as Viewer — not Editor.
• One group per user: A user belongs to at most one project group. Promoting a user to a higher group automatically removes them from the lower group.

Per-Object Role Overrides

Project group roles apply uniformly to all objects in a project by default. However, Admins can override a group's role on a specific object:

• Example: Members have Editor access project-wide, but a sensitive dataset is set to Viewer for the Members group — so Members can only read that dataset.
• Example: The Visitors group is set to Deny Access on a specific SAR report — Visitors cannot see that report even though they can view other objects in the project.

The Owners group role cannot be overridden. It is always Admin.

Public vs Private Projects

Tenant-Level Controls

Organization administrators can enable or disable certain capabilities:

When sharing is disabled, the Share button is hidden and all access control modification
endpoints are blocked.