---
title: "User Roles - Advanced Settings"
url: "https://help.tabidoo.cloud/en/article/user-roles-advanced-settings"
language: "en"
last_updated: "2026-04-01T12:43:56.712Z"
---

# User Roles - Advanced Settings

In this chapter, we will show you how to set up user roles so that users can edit (add and delete) only their own records. At the same time, these roles will allow the users to see the records of other users, which they are unable to edit.

### Basic Setup

It is necessary to create **two roles**:

-   One that **allows editing** of the user’s own records
-   One that **prevents editing** of other users’ records

The table must include a field that can **identify the user**, e.g., a system field called **"Created"** (Author of the record).

In the Developer level section, select the field **Schema item internal name** and name the item "Author".

* * *

## Role: Editing User’s Own Records

Steps:

-   Create a new role, e.g., **"User - Editing of Records"**
-   Set the **Application Level Permissions** as needed
-   In the table tab, set access to **Write**

![](https://cdn-assets.productfruits.com/c372149e-2227-4b02-a2ac-96cba168fa4e)

*Application permissions*

-   Add the following condition:

```javascript
doo.model.Author.value === doo.currentUser.login.value || !doo.model.Author.value
```

![](https://cdn-assets.productfruits.com//70bb153f-f5f4-4b78-8dd9-ea5119a0708b)

Note on Reports and Role Permissions

When a user creates a new report in the application, the default permission for each role is set to **"Not set"**.  
This means that all roles will be able to see the report unless access is explicitly restricted.

If the report should be visible only to a specific role, you need to:

Manually set the report access to **Deny** for all other roles  
**or**

Restrict access to the **table** the report is based on  
 

* * *

### Role: Viewing Other Users’ Records

Steps:

-   Create a new role, e.g., **"User - Reading of Records"**
-   Set the Application Level Permissions according to your requirements.
-   In the table tab, set access to **Read**
-   Add the following condition:

```javascript
doo.model.<[Author(Author)]>.value !== doo.currentUser.<[(Login)]>
```

![](https://cdn-assets.productfruits.com//dfe496e2-2fdb-4b09-b8b3-0b0b8f01984d)

Then assign both roles to users. This allows them to:

-   **Edit their own records**
-   **View (but not edit) others’ records**  
     

* * *

### Example: Viewing Records Assigned to Me (URL / Mailto link)

-   Create a field of type **URL / Mailto Link**
-   Create a **Calculated Field** and insert the URL/Mailto field into the formula editor
-   Add `?.href` to the end

![](https://cdn-assets.productfruits.com/43929610-e138-403f-a29e-3bb101519409)

-   Next, set the condition for the role:

```plaintext
doo.model.<[URL (URL)]> === doo.currentUser.<[Login (login)]>
```

If the field is a **link to another table**, follow the same logic and display the field in a Calculated Field.  
 

* * *

  
  
**Role Settings for Fields from a Linked Table**

I have a table that contains a **“Link to table”** field pointing to the **Users** table. I want to set up permissions so that a user can only access records where the assigned user matches the currently logged-in user.

To compare a value from a linked table, you always need to use `**.value**`, followed by the specific column you want to compare.

In this case, I am comparing the **user ID**, so the expression looks like this:

```javascript
doo.model.<[Users (users)]>.value.x_ID === doo.currentUser.x_ID
```

This expression means: **The ID of the assigned user in the record** (retrieved via the linked field to the Users table) **must match the ID of the currently logged-in user**.  
  
 Role condition example in Tabidoo

```javascript
doo.model.<[Responsible person (assignedTo)]>.login === doo.currentUser.<[Login (login)]> ||
doo.model.<[Creator (creator)]>.value === doo.currentUser.<[Login (login)]> ||
doo.model.<[Watch (watch)]>.login._$$list === doo.currentUser.<[Login (login)]>.value ||
doo.model.<[Assigned department (assignedDepartment)]>.department === doo.currentUser.<[Department (department)]>
```

* * *

### Explanation

You're working with fields that are **linked to other tables**, and you're building a condition to define **role-based access**. Here's what each part does:

👉 `doo.model.<[Responsible person (assignedTo)]>.login === doo.currentUser.<[Login (login)]>`

Checks if the **responsible person** in the record is the **currently logged-in user**.

👉 `doo.model.<[Creator (creator)]>.value === doo.currentUser.<[Login (login)]>`

Compares the **creator (a system field)** of the record to the **current user**.

👉 `doo.model.<[Watch (watch)]>.login._$$list === doo.currentUser.<[Login (login)]>.value`

Checks if the current user is listed among **watchers** (many-to-many relation).

Use `._$$list` to fetch **all users in a many-to-many link**.

Tip: Use `._$$count` if you need to compare counts instead.

👉 `doo.model.<[Assigned department (assignedDepartment)]>.department === doo.currentUser.<[Department (department)]>`

Compares the **assigned department** in the record to the **department of the current user**.

* * *

###  Comparing Lists Between Tables (Many-to-Many)

```javascript
doo.model.<[Vacancy (vacancy)]>.value.user._$$list in doo.currentUser.<[Department (department)]>.value.user._$$list 
```

This example compares **two many-to-many fields**.

Both sides return a **list of users** (via `._$$list`).

The in operator compares the values returned by both expressions.

This is useful for checking overlaps between two related collections.

* * *

### Important Notes on Role Conditions

**Avoid** `**contains**` – it checks all values in a list and can lead to **unintended matches**.  
Example: filtering by `"Ing."` would select **all engineers**, not just one specific person.

**Use** `**===**` **for exact matches** whenever possible.

**Visibility settings work on many-to-many (n:m) fields!**  
You can safely use `._$$list` and `in` to manage access logic involving linked tables.

* * *

**Tip:**  
It’s also possible to use the **fixed filter** ***Logged in User*** in case of a **many-to-many** relationship, as long as the relation is linked to the **Login** field.  
This allows you to easily limit records based on the currently logged-in user even within n:m relationships.