---
title: "Access Control Model"
slug: "ideation-access-control-model"
updated: 2026-10-14T14:03:09Z
published: 2026-10-14T14:03:09Z
canonical: "docs.discngine.com/ideation-access-control-model"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://docs.discngine.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 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**:

| Role / Permission | Create | Read | Update | Delete | Manage Permissions |
| --- | --- | --- | --- | --- | --- |
| **Admin** | x | x | x | x | x |
| **Editor** | x | x | x |  |  |
| **Viewer** |  | x |  |  |  |
| **Deny Access** |  |  |  |  |  |

- **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](/public/docs/ideation-access-control-model#perobject-role-overrides) below).

### Securable Objects

The following object types can have access control:

| Object Type | Description |
| --- | --- |
| **Project** | Organizational container for datasets & reports |
| **Dataset** | Collection of structures with activity data |
| **SAR Report** | Interactive SAR visualization |

### 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:

| Group | Default Role | Typical Use |
| --- | --- | --- |
| **Owners** | Admin | Project administrators |
| **Members** | Editor | Active contributors |
| **Visitors** | Viewer | Stakeholders with read-only needs |

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

| Aspect | Private | Public |
| --- | --- | --- |
| Default visibility | Only explicit group members | All authenticated users |
| Visitors group | Must be explicitly populated | All non-member users are implicit Visitors |
| Visitor management | Add/remove individual users | Cannot manage individual Visitors (all users are Visitors by default) |
| Group overrides | All three groups can have per-object overrides | All three groups can have per-object overrides |

### Tenant-Level Controls

Organization administrators can enable or disable certain capabilities:

| Parameter | Effect |
| --- | --- |
| CAN_CREATE_PROJECT | Controls whether users can create new projects |
| CAN_SHARE_ENTITIES | Controls whether sharing (direct grants, group management) is enabled |

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