[GH-ISSUE #22491] issue: Open Terminal, Edit Terminal Connection, Add Access, not showing logged in user #90463

New Issue

2026-05-15T15:43:19-05:00

GiteaMirror commented

2026-05-15 15:43:19 -05:00

Originally created by @toralux on GitHub (Mar 9, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/22491

Check Existing Issues

I have searched for any existing and/or related issues.
I have searched for any existing and/or related discussions.
I have also searched in the CLOSED issues AND CLOSED discussions and found no related items (your issue might already be addressed on the development branch!).
I am using the latest version of Open WebUI.

Installation Method

Docker

Open WebUI Version

v0.8.10

Ollama Version (if applicable)

No response

Operating System

Docker container

Browser (if applicable)

Chrome 145

Confirmation

I have read and followed all instructions in README.md.
I am using the latest version of both Open WebUI and Ollama.
I have included the browser console logs.
I have included the Docker container logs.
I have provided every relevant configuration, setting, and environment variable used in my setup.
I have clearly listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc).
I have documented step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation. My steps:
Start with the initial platform/version/OS and dependencies used,
Specify exact install/launch/configure commands,
List URLs visited, user input (incl. example values/emails/passwords if needed),
Describe all options and toggles enabled or changed,
Include any files or environmental changes,
Identify the expected and actual result at each stage,
Ensure any reasonably skilled user can follow and hit the same issue.

Expected Behavior

In "Admin Panel, Integrations, Open Terminal, Edit Terminal Connection, Add Access", when I search for "Anders Johansen" the dialog is expected to show the two registered users matching that search pattern - including the currently logged in user "Tor Anders Johansen", but only one of these users show up in the Web UI dialog as if the currently logged in user is filtered away.

Actual Behavior

Steps to Reproduce

Inn "Add User", search for "Anders Johansen" (matching my list of registered users).

What Web UI in Chrome shows

UI (showing 1 user only, one expected user is missing):

What REST-api results in Chrome shows

REST API (returning 2 users as expected)
HTTP GET api/v1/users/search?page=1&query=anders+johansen&order_by=name&direction=asc

{
    "users": [
        {
            "status_emoji": null,
            "status_message": null,
            "status_expires_at": null,
            "id": "98c9a8be-edf3-4d35-aa4f-...b",
            "name": "Tor Anders Johansen",
            "email": "some-mail-address@gmail.com",
            "role": "admin",
            "bio": null,
            "groups": [],
            "is_active": false
        },
        {
            "status_emoji": null,
            "status_message": null,
            "status_expires_at": null,
            "id": "a42061f3-b150-49b2-850b-...",
            "name": "Tor Anders Johansen",
            "email": "some-other-mail-address@hotmail.com",
            "role": "admin",
            "bio": null,
            "groups": [],
            "is_active": false
        }
    ],
    "total": 2
}

Logs & Screenshots

Screenshot of the UI and API-response together

Two users from REST-api.tiff

Additional Information

Could it be because the two users share the exact same display name? (One is the first/initial admin user, the second is later on registered using Oauth 2.0 and an identity provider, and both users share the same display name).

Originally created by @toralux on GitHub (Mar 9, 2026). Original GitHub issue: https://github.com/open-webui/open-webui/issues/22491 ### Check Existing Issues - [x] I have searched for any existing and/or related issues. - [x] I have searched for any existing and/or related discussions. - [x] I have also searched in the CLOSED issues AND CLOSED discussions and found no related items (your issue might already be addressed on the development branch!). - [x] I am using the latest version of Open WebUI. ### Installation Method Docker ### Open WebUI Version v0.8.10 ### Ollama Version (if applicable) _No response_ ### Operating System Docker container ### Browser (if applicable) Chrome 145 ### Confirmation - [x] I have read and followed all instructions in `README.md`. - [x] I am using the latest version of **both** Open WebUI and Ollama. - [x] I have included the browser console logs. - [x] I have included the Docker container logs. - [x] I have **provided every relevant configuration, setting, and environment variable used in my setup.** - [x] I have clearly **listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup** (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc). - [x] I have documented **step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation**. My steps: - Start with the initial platform/version/OS and dependencies used, - Specify exact install/launch/configure commands, - List URLs visited, user input (incl. example values/emails/passwords if needed), - Describe all options and toggles enabled or changed, - Include any files or environmental changes, - Identify the expected and actual result at each stage, - Ensure any reasonably skilled user can follow and hit the same issue. ### Expected Behavior In "Admin Panel, Integrations, Open Terminal, Edit Terminal Connection, Add Access", when I search for "`Anders Johansen`" the dialog is expected to show the two registered users matching that search pattern - including the currently logged in user "`Tor Anders Johansen`", but only one of these users show up in the Web UI dialog as if the currently logged in user is filtered away. ### Actual Behavior <img width="507" height="303" alt="Image" src="https://github.com/user-attachments/assets/207eae04-a957-4bfc-9a38-b41e413354e5" /> ### Steps to Reproduce Inn "Add User", search for "`Anders Johansen`" (matching my list of registered users). ### What Web UI in Chrome shows UI (showing 1 user only, one expected user is missing): <img width="507" height="303" alt="Image" src="https://github.com/user-attachments/assets/207eae04-a957-4bfc-9a38-b41e413354e5" /> ### What REST-api results in Chrome shows REST API (returning 2 users as expected) HTTP GET api/v1/users/search?page=1&query=anders+johansen&order_by=name&direction=asc ``` json { "users": [ { "status_emoji": null, "status_message": null, "status_expires_at": null, "id": "98c9a8be-edf3-4d35-aa4f-...b", "name": "Tor Anders Johansen", "email": "some-mail-address@gmail.com", "role": "admin", "bio": null, "groups": [], "is_active": false }, { "status_emoji": null, "status_message": null, "status_expires_at": null, "id": "a42061f3-b150-49b2-850b-...", "name": "Tor Anders Johansen", "email": "some-other-mail-address@hotmail.com", "role": "admin", "bio": null, "groups": [], "is_active": false } ], "total": 2 } ``` ### Logs & Screenshots Screenshot of the UI and API-response together [Two users from REST-api.tiff](https://github.com/user-attachments/files/25837679/Two.users.from.REST-api.tiff) ### Additional Information Could it be because the two users share the exact same display name? (One is the first/initial admin user, the second is later on registered using Oauth 2.0 and an identity provider, and both users share the same display name).

GiteaMirror added the bug label 2026-05-15 15:43:19 -05:00

GiteaMirror closed this issue

2026-05-15 15:43:20 -05:00

GiteaMirror commented

2026-05-15 15:43:21 -05:00

@toralux commented on GitHub (Mar 9, 2026):

I have done some investigation. It looks like the problem is that the currently logged in user (Tor Anders Johansen) is filtered out from the list, cannot select the logged in user.

The root cause is this line in MemberSelector.svelte:

{#each users as user, userIdx (user.id)}
  {#if user?.id !== $_user?.id}
    <button ...>
      ...
    </button>
  {/if}
{/each}

$_user is the Svelte store for the currently logged-in user (imported from $lib/stores).

The {#if user?.id !== $_user?.id} condition explicitly excludes the logged-in user from the search results list.

This is a common and intentional design choice in many apps: you typically don't let someone grant access to themselves (since they already have it implicitly as owner/creator), or to avoid self-sharing loops in permissions.

Is this by design or is this a bug? I would expect that I can select the currently logged in user as well?

@toralux commented on GitHub (Mar 9, 2026): I have done some investigation. It looks like the problem is that the currently logged in user (Tor Anders Johansen) is filtered out from the list, cannot select the logged in user. The root cause is this line in MemberSelector.svelte: ``` {#each users as user, userIdx (user.id)} {#if user?.id !== $_user?.id} <button ...> ... </button> {/if} {/each} ``` $_user is the Svelte store for the currently logged-in user (imported from $lib/stores). The {#if user?.id !== $_user?.id} condition explicitly excludes the logged-in user from the search results list. This is a common and intentional design choice in many apps: you typically don't let someone grant access to themselves (since they already have it implicitly as owner/creator), or to avoid self-sharing loops in permissions. Is this by design or is this a bug? I would expect that I can select the currently logged in user as well?

GiteaMirror commented

2026-05-15 15:43:22 -05:00

@tjbck commented on GitHub (Mar 11, 2026):

Addressed in dev!

@tjbck commented on GitHub (Mar 11, 2026): Addressed in dev!

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/open-webui#90463