bug: Role permission list shows IDs and fails to load in Superset v6

[murattkoc]

Bug Description

When attempting to view or edit a role in Apache Superset v6, the permissions list fails to load properly.

Instead of displaying human-readable permission names, the UI only shows internal database IDs (e.g., 7, 15, 30, 31) without any descriptive labels.

The UI also shows the error message: "There was an error loading permissions".

Observed Behavior
Permissions dropdown displays raw numeric IDs instead of permission names
No descriptive labels are shown for permissions
UI shows a toast error: "There was an error loading permissions"
API / Network Error

Backend request returns HTTP 400 Bad Request with the following response:

{
"message": "Filter column: id not allowed to filter"
}

Screenshots

Screenshot 1: https://github.com/user-attachments/assets/755b48c8-ef13-4e8e-ac65-83d7cd08ef59

Environment

Superset version: 6.1.0
Python version: 3.9
Node version: 16
Browser: Firefox

[murattkoc]

@dosubot What do you think about this? What do I need to do for final production? Should I write the code in the configOverrides section of ks8 superset.yml? Or will this bug be fixed with the latest version?

[dosubot]

@murattkoc Good questions. Here's the situation:

Is this going to be fixed upstream? As of now, this bug is not fixed in the core codebase. The root cause is in Flask-AppBuilder's PermissionViewMenuApi which doesn't declare the needed search_columns for dot-notation relationship fields. While several recent PRs have improved related areas (pagination, duplicates, rate limiting), the core filter column issue remains unresolved [1]. It's unclear when a permanent fix will land since it requires changes in Flask-AppBuilder itself.

For production on k8s — yes, you should put the workaround in your configOverrides section. Here's exactly what to add to your Helm values.yaml:

configOverrides:
  fix_permissions_filter: |
    from flask_appbuilder.models.sqla.filters import FilterContains
    from flask_appbuilder.security.sqla.apis import PermissionViewMenuApi
    from superset.security import SupersetSecurityManager

    class SupersetPermissionViewMenuApi(PermissionViewMenuApi):
        search_columns = ["id", "permission.name", "view_menu.name"]

        def _init_properties(self):
            super()._init_properties()
            for col in ["permission.name", "view_menu.name"]:
                self._filters._search_filters[col] = [
                    FilterContains(col, self.datamodel)
                ]

    class CustomSecurityManager(SupersetSecurityManager):
        permission_view_menu_api = SupersetPermissionViewMenuApi

    CUSTOM_SECURITY_MANAGER = CustomSecurityManager

This gets appended to superset_config.py at runtime [2] [3], and Helm will automatically restart your pods when the config changes via checksum annotations [4].

Note: If you already have a CUSTOM_SECURITY_MANAGER defined elsewhere in your config (e.g., for OAuth), you'll need to merge the permission_view_menu_api attribute into your existing custom security manager class rather than creating a separate one.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[murattkoc]

@dosu, Unfortunately, it didn't work.

[dosubot]

@murattkoc Sorry about that. After further investigation, the workaround I suggested likely doesn't work because Flask-AppBuilder doesn't expose permission_view_menu_api as an overridable attribute on the security manager. Unlike role_api and user_api (which Superset does override), the PermissionViewMenuApi is auto-registered by FAB during app initialization, so setting that attribute on a custom security manager has no effect [1].

Additionally, the issue may be compounded by PR #38387 (merged March 2026), which converted the permissions dropdown to an AsyncSelect with server-side search — meaning it now actively sends filter queries (using permission.name and view_menu.name with the ct operator) to the permissions API when you type [2]. This is what triggers the "Filter column not allowed" error.

To help you further, I need a bit more information:

1. What's the exact URL and response in the Network tab when the error fires? (Is it filtering by id, permission.name, or something else?)
2. How did you install Superset 6.1.0? — official Docker image, built from source/branch, or Helm chart with a specific tag?
3. Do you already have a CUSTOM_SECURITY_MANAGER defined elsewhere in your config (e.g., for OAuth)?

A potential alternative approach would be to use the FLASK_APP_MUTATOR hook to patch the API class after FAB registers it [3], but I'd like to confirm the exact error details first so the fix actually targets the right problem.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[murattkoc]

@dosu When and with which version will this bug be fixed?

[dosubot]

@murattkoc Unfortunately, there is no scheduled fix or target version for this bug at this time. The issue is tracked in #39967, but no open PR currently addresses it, and no milestone has been assigned [1].

The root cause is in Flask-AppBuilder (the underlying framework), and the community consensus so far leans toward a Superset-side fix rather than waiting for an upstream FAB update — but no one has submitted that fix yet.

If this is blocking you in production, your options are:

1. Contribute a fix — a PR that properly overrides PermissionViewMenuApi within Superset's security layer (similar to how SupersetRoleApi and SupersetUserApi already override FAB defaults) would likely be welcomed by maintainers.
2. Use a deployment workaround — though as you noted, the configOverrides approach has complications due to how FAB registers the API. A FLASK_APP_MUTATOR approach that patches the already-registered API view might be more reliable.
3. Wait — but there's no ETA since no fix is actively in progress.

Given this is impacting users on v6, flagging it with a comment on #39967 requesting prioritization might help get maintainer attention.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[murattkoc]

@dosu,
georchestra/superset-core#56
the link above will this solve the problem?

[dosubot]

@murattkoc The georchestra/superset-core#56 issue is describing the exact same bug you're facing — it references apache/superset#40293 which is a duplicate of #39967 [1].

That said, the georchestra issue itself doesn't contain a fix — it just links to the same workaround we've been discussing.

What's interesting from #40293 is that a maintainer (@dpgaspar) stated it was fixed by PR #39465 on master, and closed the issue. However, another user then reported it's still broken in Superset 6.1.0 [1] — which matches your experience.

The good news is that the configOverrides workaround does work for others deploying via Helm. One user (@jeremy449) shared a working Helm config [1]. The key difference from what I previously suggested is the YAML formatting — using > (folded block scalar) with blank lines between imports:

configOverrides:
  flask_override: >
    from flask_appbuilder.models.sqla.filters import FilterContains

    from flask_appbuilder.security.sqla.apis import PermissionViewMenuApi

    from superset.security import SupersetSecurityManager

    class SupersetPermissionViewMenuApi(PermissionViewMenuApi):
        search_columns = ["id", "permission.name", "view_menu.name"]

        def _init_properties(self) -> None:
            super()._init_properties()
            for col in ["permission.name", "view_menu.name"]:
                self._filters._search_filters[col] = [
                    FilterContains(col, self.datamodel)
                ]

    class CustomSecurityManager(SupersetSecurityManager):
          permission_view_menu_api = SupersetPermissionViewMenuApi

    CUSTOM_SECURITY_MANAGER = CustomSecurityManager

The blank lines between from statements are critical for proper YAML parsing. Could you try this exact formatting? If you already tried this and it still didn't work, the issue might be that you have another CUSTOM_SECURITY_MANAGER defined elsewhere in your config that's overriding this one.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[murattkoc]

@dosu
I did this in the ks8 yml file, but it didn't work. Could it be that this change is being overridden somewhere else? It wasn't an override.
I set the dockerfile "FROM apache/superset:latest". Is the override file located somewhere else?

[murattkoc]

@dosu
I did this in the ks8 yml file, but it didn't work. Could it be that this change is being overridden somewhere else? It wasn't an override.
I set the dockerfile "FROM apache/superset:latest". Is the override file located somewhere else?

[murattkoc]

@dosu
I defined it inside configOverrides but it didn't work.

[dosubot]

@murattkoc The approach is correct and confirmed to work by other users — the issue is most likely a YAML formatting problem that silently breaks the Python code when rendered.

Since you're using FROM apache/superset:latest in a Dockerfile with a k8s deployment (not the official Helm chart), I want to clarify: how are you injecting the configOverrides into your container?

If you're NOT using the official Superset Helm chart, then configOverrides in your YAML won't do anything on its own — it's a Helm-specific mechanism. Instead, you need to get this Python code into a file that Superset actually loads.

For a custom Docker image (FROM apache/superset:latest), do this instead:

Create a file called superset_config.py (or add to your existing one) and copy it into the image:

FROM apache/superset:latest
COPY superset_config.py /app/pythonpath/superset_config.py

Where superset_config.py contains:

from flask_appbuilder.models.sqla.filters import FilterContains
from flask_appbuilder.security.sqla.apis import PermissionViewMenuApi
from superset.security import SupersetSecurityManager

class SupersetPermissionViewMenuApi(PermissionViewMenuApi):
    search_columns = ["id", "permission.name", "view_menu.name"]

    def _init_properties(self) -> None:
        super()._init_properties()
        for col in ["permission.name", "view_menu.name"]:
            self._filters._search_filters[col] = [
                FilterContains(col, self.datamodel)
            ]

class CustomSecurityManager(SupersetSecurityManager):
    permission_view_menu_api = SupersetPermissionViewMenuApi

CUSTOM_SECURITY_MANAGER = CustomSecurityManager

Alternatively, if you don't want to rebuild the image, mount this file as a ConfigMap in your k8s deployment:

apiVersion: v1
kind: ConfigMap
metadata:
  name: superset-config
data:
  superset_config.py: |
    from flask_appbuilder.models.sqla.filters import FilterContains
    from flask_appbuilder.security.sqla.apis import PermissionViewMenuApi
    from superset.security import SupersetSecurityManager

    class SupersetPermissionViewMenuApi(PermissionViewMenuApi):
        search_columns = ["id", "permission.name", "view_menu.name"]

        def _init_properties(self) -> None:
            super()._init_properties()
            for col in ["permission.name", "view_menu.name"]:
                self._filters._search_filters[col] = [
                    FilterContains(col, self.datamodel)
                ]

    class CustomSecurityManager(SupersetSecurityManager):
        permission_view_menu_api = SupersetPermissionViewMenuApi

    CUSTOM_SECURITY_MANAGER = CustomSecurityManager

Then mount it in your deployment:

volumeMounts:
  - name: superset-config
    mountPath: /app/pythonpath/superset_config.py
    subPath: superset_config.py
volumes:
  - name: superset-config
    configMap:
      name: superset-config

The key point is: the file must end up at /app/pythonpath/superset_config.py inside the container. Can you confirm whether you're using the official Helm chart or a custom k8s deployment?

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[rusackas]

This is quite the dosu conversation! :) Do you have an LLM account like Claude/Codex/etc? Maybe you can have it take stock of the situation on a local branch and see about opening a fix? That might at least allow you to rule out the yaml indentation problem and/or make sure #39465 is on whatever version of the code you're using.